Switch statement vs Polymorphism

[Alexander Sales]

I'm confused with this statement.

My wild theories that you don't need to know right now:

    The switch statement is certainly better than a long series of "if" statements, but I have found that whenever I start to implement a
 switch statement, I can almost always find a better program design - usually by using an array or making a method that has more 
functionality. The only time that a switch statement is the right choice is when the evaluation leads to radically different functionality. And
 in those cases, a switch statement can almost always be replaced by polymorphism (a construct in object oriented programming)

will you explain it in code?

it was taken from this url. http://www.javaranch.com/drive/switch.html

[Jesper de Jong]

Do you know what polymorphism is? (There are different forms of polymorphism, but usually people mean subtype polymorphism).

Suppose you want to model animals in a program. You could write code like this:

class Dog {
    // ...
}

class Cat {
    // ...
}

public class Demo {
    public static void makeSound(Object o) {
        if (o instanceof Dog) {
            System.out.println("Woof!");
        }
        else if (o instanceof Cat) {
            System.out.println("Meow!");
        }
        else {
            System.out.println("Unknown animal!");
        }
    }

    public static void main(String[] args) {
        Dog fifi = new Dog();
        Cat garfield = new Cat();

        makeSound(fifi);
        makeSound(garfield);
    }
}

The design of this code is very poor, from an object oriented programming point of view. The makeSound method in class Demo has a chain of if ... else if ... statements to determine with which animal we are dealing. Suppose that you'd add a new animal class, then you'd have to change the makeSound method also to add the sound of the new animal.

In a well-designed program, you would put everything that is necessary to know about a specific animal in the class for that animal. Note that in the program above, the knowledge about what sound to make is outside the classes Dog and Cat.

It looks innocent in that little example, but when you are writing a larger and more complex program, maintainability and extensibility become more and more important. If you need to modify code in a dozen places to add a new animal, then the program is hard to extend.

It's much better to do something like this:

abstract class Animal {
    public abstract void makeSound();
}

class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}

class Cat extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Meow!");
    }
}

public class Demo {
    public static void main(String[] args) {
        Animal fifi = new Dog();
        Animal garfield = new Cat();

        fifi.makeSound();
        garfield.makeSound();
    }
}

In this example, we make use of subtype polymorphism. Note that an Animal can be either a Dog or a Cat (or any other animal, if you add more classes that extend Animal). In the main method, you don't even need to know what kind of animal you call makeSound on - it will automatically go to the method in the appropriate class.

If you would want to add another animal in the above code, you'd just have to add a class that extends Animal. All the functionality of the animal, such as what sound it makes, is contained in that class, and not scattered around in a dozen places. So, a program with this design is much easier to extend.

[Alexander Sales]

So that's how it is.. i was confused on the statement in using objects in switches..first thing that comes into my mind was the factory pattern. thanks sir Jesper. It's well explained.

[Campbell Ritchie]

Remember that the values after the case keyword in a switch block must be compile-time constants, and they must be ints (or can be cast to int) or enum members (Java5+) or Strings (Java7 only). So that restricts the range of values permitted after case.