SCJP for Java 6 book by Sierra and Bates covariant return code example question

[alexandru costea]

I've found this code in the book used to illustrate covariant method returns:

public abstract class Animal {}
public class Bear extends Animal{}
public class Test{
    public Animal go(){
        return new Bear();
    }
}

Now this would show in my interpretation that you can return a subtype of the method return type that subtype being Bear. But since the point, as I see it, is to be able to return a subtype that will be put in a supertype reference (an Animal holding a Bear object) how would this make any sense in the real world as I will not be able to instantiate Animal?

Thank you,
Alex.

[Rajeev Rnair]

Hi Alexandru, welcome to the ranch!
I am not sure I understood your question completely! You cannot instantiate an abstract class, but you can instantiate the concrete sub class, which is what the above example is showing!
Here is a class which implements an interface like the above code!

public interface Bounceable {}   
public class Ball implements Bounceable{}   
public class Test{   
    public Bounceable go(){   
        return new Ball();   
    }   
}  

[alexandru costea]

This example is from the book and I am puzzled as to its usefulness regarding polymorphism. Let me try and explain myself better.

This is a piece of code that explains my point.

    
class Animal {} //this is no longer abstract

class Bear extends Animal{}

public class Test
   {

    public Animal go()
        {
        return new Bear();
        }

    public static void main (String[] args)
        {
        Animal[] herd= new Animal[10];
        Animal a;
        Animal a1=new Animal();
        Bear b;
        a=go();
        b=go();
        
        herd[0]=a;
        herd[1]=b;
        herd[2]=a1;
        herd[3]=go();
        }
    }

So in this example I can take full use of polymorphism maybe with an array(herd) of Animal references that hold Animals as well as Bears returned by the go function or created or returned otherwise thus giving me the opportunity to call a function that exists in Animal and is overridden in Bear in a polymorphic way. The key point is that I can use the Animal class polymorphic as opposed to the example in the book.

public abstract class Animal {}
public class Bear extends Animal{}
public class Test
    {
    private Animal a;//Compiler nasty stuff
    public Animal go()
        {
        return new Bear();
        }
    }

Here I won't be able to instantiate an Animal object so I won't be able to to hold a Bear object into an Animal reference var. So it occurs to me that this is a faulty example because the method return type is Animal (which can never be instantiated) but the return object will always be a Bear so I will always use a Bear reference to hold the return value and thus making Animal as the method return type seem useless.

What I am asking is if I am right and the example provide in the book while being valid in syntax it doesn't really explain the issue at hand to the full extent. The thing is that while it illustrates the covariant return methods the example would never be useful in a real life endeavor. I mean since you can't have an instance of Animal why would you ever have it as a return type for a method.

If we were talking about an interface I think it would actually make a lot of sense but I don't get the point of the return type being abstract.

Thank you,
Alex.

[Michael Angstadt]

Hi Alex!

...but the return object will always be a Bear so I will always use a Bear reference to hold the return value and thus making Animal as the method return type seem useless.

You're right--in your example, it doesn't make a difference whether go() returns an Animal or a Bear because, looking at the method body, we know it will always return a Bear. But what if you didn't know what the method was returning?

public abstract class Zoo{
  public abstract Animal getMostPopularAnimal();
  public String toString(){
    return "The zoo's most popular animal is " + getMostPopularAnimal();
  }
}
public SpringfieldZoo extends Zoo{
  public Animal getMostPopularAnimal(){
    return new Bear();
  }
}
public NewYorkZoo extends Zoo{
  public Animal getMostPopularAnimal(){
    return new Elephant();
  }
}

In this case, we can never be sure what getMostPopularAnimal() will return because the classes that extend Zoo can return any kind of Animal.

[alexandru costea]

Hi Michael,

the question though is why on earth would you choose to have the return type Animal when you will never have an instance of Animal created and will always return a Bear. I am saying that the example is faulty because in real life you will never ever find it useful. As I have written in in my first sequence of code class Animal is no longer abstract so it makes sense to have it as a return type whether you return an Animal or a Bear because you would take advantage of polymorphism.

In the case of the code in the book it would make no sense to ever put in a return type that you know will never occur. I mean you would put a return type and then be able to return subclasses of the return type for its usefulness but its useless having a piece of code, that can allow a variation, that you know will never happen.

It's like doing something just for the sake of doing it. The thing that I wanted is for someone to tell me that yes that piece of code could very well be changed to a return type Bear since it will never be able to return an Animal which is abstract and cannot be instantiated. I understand what it's trying to portray but I think it would have done it better with a non abstract class. It's legal this way too but it might have helped to have both pieces of code.

Thank you for your help. I think that that's just it but I wanted someone to confirm. So can you confirm my hypothesis? :P

Alex.

[Prithvi Sehgal]

Hello Alex,

I apologize, i haven't read the whole thread, but skimmed through it and only got a fair idea that you want to know
why Animal has been put as the return type when it is abstract and not useful.

Well, i think so, have you heard something like 'Programming to an interface'. Please have a look at Strategy Pattern specially.
In this way, you are hiding the implementation from the user. Lets say your class was not abstract but an interface for suppose.
We always promote Programming to Interfaces, because they hide your implementation details. The people who are using your
application will never know what concrete implementation you are using.

Do you know java.util.Calendar is even an abstract class?

Hope this helps,

[Bert Bates]

While this doesn't completely answer the question, keep in mind that the example you cite from the book is inside an "exam watch". What this means is that this isn't necessarily a practical example, for the real world, it's more about a 'trick' you might encounter on the exam.

hth,

Bert

[alexandru costea]

Thank you very much Bert that was the answer I was looking for. I knew it is legal(& good to watch for at the exam) and regarded it as such but it was the practical use that I wanted a confirmation for.

Alex.