Question

Suppose I am designing something like the following interface:

public interface MyInterface{
  public MyInterface method1();
  public void method2(MyInterface mi);
}

However, there is the caveat that the return type for method1 and the parameter for method2 match the concrete implementation and not just MyInterface. That is, if I have MyInterfaceImpl that implements MyInterface, it needs to have the following:

public class MyInterfaceImpl implements MyInterface{
  @Override
  public MyInterfaceImpl method1(){...}

  @Override
  public void method2(MyInterfaceImpl mi){...}
}

As written above, method1 won’t cause any compile errors, but there is nothing guaranteeing that the return type matches in all implementations. Of course method2 won’t even compile because the signature does not match the interface.

One candidate solution is to use self-referential or recursive bounds in generics:

public interface MyInterface<T extends MyInterface<T>>{
  public T method1();
  public void method2(T mi);
}

public class MyInterfaceImpl implements MyInterface<MyInterfaceImpl>{
  @Override
  public MyInterfaceImpl method1();

  @Override
  public void method2(MyInterfaceImpl mi);
}

This would get me what I want with one exception: other implementations might pass the wrong generic type (nothing forces T to match the concrete type). So potentially someone else could implement the following:

public class NotMyInterfaceImpl implements MyInterface<MyInterfaceImpl>{
  @Override
  public MyInterfaceImpl method1();

  @Override
  public void method2(MyInterfaceImpl mi);
} 

That would compile just fine even though NotMyInterfaceImpl should implement MyInterface<NotMyInterfaceImpl>.* That makes me think I need something else.

*Note that I don’t think I’m trying to violate LSP; I’m OK with the return type/parameter being subclasses of NotMyInterfaceImpl.

So I don’t know of a clean way to do this. That leads me to believe that I might be focusing too much on implementation details in the interface, but it doesn’t seem that way to me. Is there any way to do the type of thing I described, or is this some kind of smell that I’m putting something in an interface that doesn’t belong there?

Answer 1

This is the exact situation faced by the Comparable interface (its compareTo method wants to take an argument the same type as the object it is called on). So what does it do? It’s simply defined as Comparable<T>. The idea is that an implementing class “should” implement Comparable with itself as the parameter (allowing it to “compare to” itself); but this is not enforced (since there is no way to do it).

Yes, as you noted, this will allow any class to implement Comparable with a parameter of any other class: class Foo implements Comparable<Bar> where Foo and Bar have no relation to each other. However, this is not really a problem.

All the methods and classes (sorting, maximum, etc.) that require Comparable objects have the following generic type constraint <T extends Comparable<? super T>>. This ensures that objects of type T are comparable with themselves. That way, it is completely type-safe. So the enforcement is not made in the declaration of the Comparable interface, but in the places that use it.

(I notice that you use <T extends MyInterface<T>> while Comparable uses simply <T>. Although <T extends MyInterface<T>> will exclude cases where the type parameter does not implement MyInterface, it will not exclude cases where the type parameter does implement MyInterface, but is different than the class. So what’s the point of half-excluding some cases? If you adopt Comparable‘s way of restricting it where they are used, it’s type-safe anyway, so there is no point in adding more restrictions.)