When Interface A defines Interface B in its method signature

Question

... how can I restrict an implementation of A to use a certain implementation of B in the method signature?

Use Case

Here is a Unit interface and two enums that implement it:

public interface Unit { ... }

public enum ForceUnit implements Unit { ... }
public enum MassUnit implements Unit { ... }

Which is used by the Property interface:

public interface Property {

    public void setUnit( Unit unit );    // for example
}

public class Force implements Property { ... }
public class Mass implements Property { ... }

Here I want to be able to enforce that:

• Force uses only ForceUnit in the setUnit signature
• Mass uses only MassUnit in the setUnit signature

---

When I try to do this, Eclipse complains:

The type Mass must implement the inherited abstract method Property.setUnit(unit)

And promptly suggests two quick fixes:

• make the class abstract, which is not an option since I want to be able to do stuff like Mass mass = new Mass();
• add the unimplemented methods with an @Override annotation. I don't know if this is the right fix, but to me this smacks of clumsiness.

---

Questions

• What options do I have to achieve what I want? Would the use of generics help here?
• Why does marking the class as abstract resolve the issue?

Answer 1

You can use generics

public interface Property<U extends Unit> {

    public void setUnit(U unit );    // for example
}

public class Force implements Property<ForceUnit> {
    @Override
    public void setUnit(ForceUnit unit) { }
}

public class Mass implements Property<MassUnit> {
    @Override
    public void setUnit(MassUnit unit) { }
}

Note: This does mean you can still do

Property raw = new Mass();
raw.setUnit(ForceUnit.NEWTON); // ClassCastException

however this will cause a class cast exception as the compiler is unable to check the raw type at run time.

What you should do is

Property<Mass> raw = new Mass();
raw.setUnit(ForceUnit.NEWTON); // doesn't compile.

Why does marking the class as abstract resolve the issue?

Making the classes abstract means that setUnit(Unit) hasn't actually been implemented but for an abstract class this is ok.