Avoiding generic types of form Foo>

Question

I frequently find myself wanting to write generic class definitions of the form

public class Foo<ActualType extends Foo<ActualType>>

For example in a setup like this:

public interface ChangeHandler<SourceType> {
    public void onChange(SourceType source);
}


public class Foo<ActualType extends Foo<ActualType>> {

    private final List<ChangeHandler<ActualType>> handlers = new ArrayList<>();

    public void addChangeHandler(ChangeHandler<ActualType> handler) {
        handlers.add(handler);
    }

    @SuppressWarnings("unchecked")
    protected void reportChange() {
        for (ChangeHandler<ActualType> handler: handlers)
            handler.onChange((ActualType) this);
    }
}


public class Bar extends Foo<Bar> {
    // things happen in here that call super.reportChange();
}


public static void main(String[] args) throws IOException {

    Bar bar = new Bar();
    bar.addChangeHandler(new ChangeHandler<Bar>() {

        @Override
        public void onChange(Bar source) {
            // Do something with the changed object
        }
    });
}

The change-event here is just an example. This is more of a general problem that I'm having whenever I would like to allow a super-class to provide functionality that is "individualized" to each specific sub-class (not sure how to phrase this better... in the example above the "individualization" is the fact that the ChangeHandler is called with an object of the actual sub-type (Bar) not with the type of the super-class (Foo) that is calling the handler).

Somehow this approach seems a bit messy to me. And it actually allows for potential issues since nothing prevents me from then defining:

public class Baz extends Foo<Bar> { /* ... */ }

Is there a cleaner alternative?

The holy grail would be some type parameter that is always defined to contain the current class, like a static version of this.getClass() that would allow me to write something like this instead:

public class Foo {

    private final List<ChangeHandler<this.Class>> handlers = new ArrayList<>();

    public void addChangeHandler(ChangeHandler<this.Class> handler) {
        handlers.add(handler);
    }

    protected void reportChange() {
        for (ChangeHandler<this.Class> handler: handlers)
            handler.onChange(this);
    }
}

Where this.Class would be equal to Bar for classes of type Bar.

Answer 1

I would recommend that we simply use <This> to represent the "self type". No need for bound, since it looks complicated, doesn't deliver the intention, and cannot enforce the constraint anyway.

public class Foo<This> {

    private final List<ChangeHandler<This>> handlers = new ArrayList<>();

    public void addChangeHandler(ChangeHandler<This> handler) {
        handlers.add(handler);
    }

    @SuppressWarnings("unchecked")
    protected void reportChange() {
        for (ChangeHandler<This> handler: handlers)
            handler.onChange( (This)this );
    }
}

Notice the cast (This)this.

See also Java generics: Use this type as return type?

Answer 2

It is a really abstract problem. In my opinion the short answer to "how to make this cleaner" is: only use generics where it is needed.

public class List<T extends List<T>>

What is this trying to express (substituted)? A list which only allows to hold (T extends) other lists which themselves hold Ts (List) which as we know from before are Lists which only allow to hold ... and so on. Kind of circular, I don't see how you would end up with something like that?

public interface ChangeHandler<SourceType> {
    public void onChange(SourceType source);
}

Why do you want to use generics here? If you want to have a change handler which can handle several resource types, then you can either create a super class from which all actual sources inherit or you create an interface which is implemented by the sources. Like that you can exactly specify what is exposed by the sources. Alternatively the source can create a source object when notifying instead of passing "this" (then it is more like a message). For example:

public interface ChangeHandler {
    public void onChange(Source source);
}

public abstract class Source {
    private List<ChangeHandler> handlers;
    protected int nr;
    public Source(int nr) {
      this.nr = nr;
    }
    public abstract Something getSomething();
    public String toString() {
        return "SRC" + nr;
    }
    ...
    private notify(int index) {
        handlers.get(i).onChange(this);
    }
}

public class Foo extends Source {
    public Foo(int nr) {
        super(nr);
    }
    public String toString() {
        return super.toString() + "Foo";
    }
    public Something getSomething() {
        return new Something();
    }
}

You never need to cast... or do you? I'm not sure if I understand the problem.

Answer 3

I never use type parameters to pass "ActualType" because then it is impossible to extend the object:

public class Bar extends Foo<Bar> {
    // things happen in here that call super.reportChange();
}
public class Bar2 extends Bar{
    // ...
}

Bar2 "ActualType" is still Bar, and there is nothing you can do: you won't be able to use ChangeHandlers for Bar2

To avoid the issue, the only possible fix I see is to delegate the cast operation to an other class (you could also use a default method in the ChangeHandler interface). Here is a possibility:

public class Foo // no more type parameter
{
    private final List<FooCaster<?>> casterHandlers = new ArrayList<>();
    
    /**
     * unsafe because you could register a ChangerHandler of any type.
     * worst of all, everything is unchecked cast so the error could show up late.
     */
    public <T> void addChangeHandler(ChangeHandler<T> handler) {
        casterHandlers.add(new FooCaster<T>(handler));
    }

    protected void reportChange() {
        for (FooCaster<?> caster: casterHandlers) {
            caster.reportChange(this);
        }
    }
    
    class FooCaster<T> {
        protected ChangeHandler<T> ch;
        protected FooCaster(ChangeHandler<T> ch) {
            this.ch = ch;
        }
        
        @SuppressWarnings("unchecked")
        public void reportChange(Foo f) {
            ch.onChange((T)f);
        }
    }
}

Personnaly in the case of broadcasting changes to listener/changehandlers, I'm enclined to externalize the process to an other class, which makes it possible to use parameter types properly and avoid unsafe casts.If you are still willing to use reportChange() from within the foo object, here is a possible implementation (otherwise you could store a T reference in the Broadcaster).

public class Broadcaster<T extends Foo> {
    protected final List<ChangeHandler<? super T>> changeHandlers;
    
    public Broadcaster() {
        this.changeHandlers = new ArrayList<>();
    }
    
    public void startListeningTo(T obj) {// only T type objects are accepted
        obj.registerBroadcaster(this);
    }
    
    public void addChangeHandler(ChangeHandler<? super T> changeHandler) {
        changeHandlers.add(changeHandler);
    }
    
    void reportChange(Foo obj) {
        T o = (T)obj;
        for(ChangeHandler<? super T> c : changeHandlers) {
            c.onChange(o);
        }
    }
}

public class Foo {
    private final List<Broadcaster<?>> broadcasters = new ArrayList<>();
    
    // cannot be accessed from outside of the package, only Broadcaster.startListeningTo(T o) can be used
    final void registerBroadcaster(Broadcaster<?> b) {
        broadcasters.add(b);
    }

    public final void reportChange() {
        for (Broadcaster<?> b: broadcasters) {
            b.reportChange(this);
        }
    }
}

public class Bar extends Foo {
    // things happen in here that call super.reportChange();
}

public static void test() {
    Broadcaster<Bar> broadcaster = new Broadcaster<>();
    broadcaster.addChangeHandler(new ChangeHandler<Bar>() {
        @Override
        public void onChange(Bar obj) {
            // do something
        }
    });
    
    //note that you can use the same broadcaster for multiple objects.
    Bar b = new Bar();
    broadcaster.startListeningTo(b);
    b.reportChange();
}

Note that you will not be able to add changeHandlers from within Bar (but is it really the object's job to register changeHandlers for itself?).