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?
Concrete methods in an interface All the methods in an interface must be abstract, you cannot have a concrete method (the one which has body) if you try to do so, it gives you a compile time error saying “interface abstract methods cannot have body”.
Concrete methods in interfaces The simplest form of this feature is the ability to declare a concrete method in an interface, which is a method with a body. A class that implements this interface need not implement its concrete method.
Java 8, yes.
It is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface. Along with abstract methods, an interface may also contain constants, default methods, static methods, and nested types. Method bodies exist only for default methods and static methods.
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.)
I believe that this cannot be done. There is simply no way to refer to an object's implementation class in the framework of generics, nor, as far as i know, any way to construct a cage out of pure generics which is capable of constraining the implementation class to match a type parameter.
The most useful thing i can suggest is using a self-referential parameter, and then always acquiring instances of implementations from factory methods which look like:
public <T extends MyInterface<T>> T newInstance();
It is easier for a camel to pass through the eye of a needle than for an instance of NotMyInterfaceImpl
to pass through that return type. So, although troublemakers could write classes which do not conform to your masterplan, they couldn't return them from factories. Unless NotMyInterfaceImpl
extended MyInterfaceImpl
; but then, in a sense, it would also be a MyInterfaceImpl
, so perhaps that would be kosher?
EDIT: A slightly more useful version of that idea is to always pass instances of implementations of the interface around in a suitably restrictive holder, like:
class Holder<T extends MyInterface<T>> {
public final T value;
}
If someone gives you a Holder<Q>
, then you know that Q
must be a version of MyInterface
bound to itself, which is what you're after.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With