"Introduction to Java programming", says:
To enable generic programming, it is a good practice to define a variable with a supertype, which can accept a value of any subtype.
Code example:
Object myObject = new Circle();
... // Some lines of code
System.out.println("The circle diameter is " +
((Circle)myObject) .getDiameter());
... // Some lines of code
Why not define myObject as a Circle type in the first place?
Lets make a simple Example with a class Fruit
public class Fruit {
public void eat() {
//some code
}
}
And two other classes
public class Banana extends Fruit{
}
//
public class Apple extends Fruit{
}
Now let´s create a Person
public class Person {
public void eat(Fruit f) {
f.eat();
}
}
Let´s use this now
public static void main(String[] args) {
Person p = new Person();
// We are creating a random Fruit, and pass it to the person to eat.
// We can´t be more specific here and don´t need to be more specific
Fruit f = getRandomFruit();
p.eat(f);
}
public static Fruit getRandomFruit() {
if(new Random().nextInt(2) == 0) {
return new Banana();
} else {
return new Apple();
}
}
I think that in this case, this example does more harm than good. To do any Circle or Shape related operations you will need to cast your current object. Other than adding potential overhead, this could lead to issues such as incompatible types.
Doing generic programming is usually recommended since it allows your code to be flexible. Unlike the example you have posted however, it is recommended only when done right. Creating everything as an object will almost always do more harm than good.
Taking the List as an example, if you where to have a method which returns an ArrayList<String> as a result: public ArrayList<String> foo(), then, you are bound to that particular type. If you want a linked list, you will probably need to write some sort of converter which creates a LinkedList<String> from an ArrayList<String>.
On the other hand, if you use the generic interface instead, your method would become something like so: public List<String> foo(). This will allow who ever consumes foo to be able to create any one of the data structures which implement the List interface without the need of going through hoops.
EDIT: As per your comment, most of the time it does not help. As I mentioned in my answer it does more harm than good. One of the instances where working with objects makes sense is the readObject() method provided by the ObjectInputStream. This method is used when you are reading a custom object, which the ObjectInputStream does not know about. Since in Java everything extends the Object class, this method yields an object. Even then, every illustration I have seen of this method they eventually cast it to something else.
If you modify the example a little bit, by deriving Circle, Square , RectAngle from Shape instead of Object, it will make good sense. Shape can have methods like getArea() and attributes like height and width, which can be overridden by derived classes.
Shape circle = new Circle();
Shape rectangle = new Rectagle();
In real life examples, it is better to use Base generic types for derived classes so that an implementation can change at run time.
If you are looking for object creation, use simple Factory.
If you are looking to change the behaviour of the object at run time, use Strategy_pattern.
If you are working on multiple strategies for feature, strategy can replaced dynamically by changing base to new derived strategy.
Have a look at below examples:
Design Patterns: Factory vs Factory method vs Abstract Factory
