Returning an objects subclass with generics

Question

With an abstract class I want to define a method that returns "this" for the subclasses:

public abstract class Foo {
    ...
    public <T extends Foo> T eat(String eatCake) {
        ...
        return this;
    }
}  

public class Eater extends Foo {}

I want to be able to do things like:

Eater phil = new Eater();
phil.eat("wacky cake").eat("chocolate cake").eat("banana bread");

Hightension

Answer 1

public abstract class Foo<T extends Foo<T>>  // see ColinD's comment
{
    public T eat(String eatCake) 
    {
        return (T)this;
    }
}

public class CakeEater extends Foo<CakeEater> 
{
    public void f(){}
}

Edit

There is no problem to require subclass behave in a certain way that's beyond what static typing can check. We do that all the time - pages and pages of plain english to specify how you write a subclass.

The other proposed solution, with covariant return type, must do the same - asking subclass implementers, in plain english, to return the type of this. That requirement cannot be specified by static typing.

Sericeous

Should be Foo<T extends Foo<T>>. This works, though you can easily make a class that will blow up with a ClassCastException when you call eat, such as class Bar extends Foo<CakeEater>. – Statism

This is the solution I ended up using, but you'll notice that the return has an unchecked cast warning. While logically it makes sense that we can cast to T as this is a subclass of T. – Hightension

Yes. In a better world, Java could have a This type, which would be very useful in a lot of cases. – Sericeous

class FakeEater extends Foo<CakeEater> { } Now take notice of the warning. – Grow

Tom, I didn't notice any warning. Maybe that's the point of your response, that there is no compile time warning. When calling FakeEater's eat there will be a a compile-time exception that the returning type is not of type FakeEater if it is being assigned to a FakeEater field. – Hightension

Could you store an instance of the subclass's class in the superclass? Maybe make in mandatory in the abstract class constructor. Calling clazz.cast(this) will then perform a typesafe cast back to the subclass type, won't it? – Footstep

Answer 2

The tasteful approach from the client point of view (which is usually the one you want to take) is to use covariant return types which was added to support generics, as Michael Barker points out.

The slightly less tasteful, but more tasteful that a cast is to add a getThis method:

public abstract class Foo<T extends Foo<T>> {
    protected abstract T getThis();

    public T eat(String eatCake) {
        ...
        return getThis();
    }
}

public class CakeEater extends Foo<CakeEater> {
    @Override protected CakeEater getThis() {
        return this;
    }
}

Grow

Hi @Tom. Why slightly less? yours is DRY, right? – Dogma

@Dogma It adds weirdo generics and a protected method to the interface, neither of which are tasteful. Though the alternative of overriding with a covariant return type does leave a load of rubbish of the form @Override public CakeEater eat(String eatCake) { super.eat(SeatCake); return this; }, which may be missed out when the base class is updated.. – Grow

Thanks @Tom. Yes that's right. but i like generics with getThis() approach; it's safer ( I did not know till I read your answer ). Unfortunately i have to override because i couldn't find a way to do child.eatParent().eatMyself(). – Dogma

It's never more "tasteful" to duplacate each and every method of super-class. just to change return-type (covariant return types are not meant for builder-style sub-classes). – Tapster

Answer 3

I don't think you need generics Java 5 (and later) has covariant return types, e.g.:

public abstract class Foo {
    ...
    public Foo eat(String eatCake) {
        ...
        return this;
    }
}  

public class CakeEater extends Foo {

    public CakeEater eat(String eatCake) {
        return this;
    }
}

Archicarp

If it's fully defined in the superclass then it creates redundant code to define it in the subclass; It could call the superclass but this seems unnecessary. It works if you cast this as type T and suppress warnings. – Hightension

It works if you cast this as type T and suppress warnings. The reason it should be return the type of the subclass is because: methodTakesCakeEater( (new CakeEater).eat("cake").eat("pie"); methodTakesCakeEater needs a CakeEater parameter. – Hightension

If a solution contains @SuppressWarnings it shouldn't be considered a solution. Just my two cents. – Togo

don't worry about warnings when you are doing edgy stuff. – Sericeous

I do not think this is a good solution to the sketched problem because it requires one to override all methods in the subclass, hardly worth the effort. The idea is to have a fluent API that subclasses can leverage, not rewrite. – Remscheid

I also do not think this is "edgy" stuff requiring one to ignore or suppress warnings – Remscheid

Coming back to this from the future, the overridden eat method should call super.eat (and ignore the return value). Also perhaps add @Override - I'm not sure that was even possible for overridden abstract methods for versions of Java in common use when this answer was written. – Grow

Answer 4

An approach I've used before to achieve similar behaviour is to have the subclass pass its type into a constructor of the (generified) parent type. By way of disclaimer I was generating the subclasses on the fly and inheritence was a bit of a cheat to keep my code generation simple, as always my first instinct is to try to remove the extends relationship altogether.

Siblee