Use of interface as parameter type in java

Question

Consider the example below.

Why is it so that I'm not allowed to use BImpl as a parameter type of method doSomething3? When I say "not allowed to", I mean that Eclipse is complaining that the doSomething3-method from the interface AInf is not implemented.

interface AInf
{
 AInf doSomething();
 BInf doSomething2();
 void doSomething3(BInf param);
}
interface BInf
{
}
class AImpl implements AInf
{
 @Override
 public AImpl doSomething() {
 // TODO Auto-generated method stub
 return null;
 }
 @Override
 public BImpl doSomething2() {
 // TODO Auto-generated method stub
 return null;
 }
 @Override
 public void doSomething3(BImpl param) // This method is not overriding the doSomething3(BInf param) from the AInf
 {
 // TODO Auto-generated method stub
 }
}
class BImpl implements BInf
{
}

Answer 1

Because doSomething3(BImpl param) doesn't implement doSomething3(BInf param).

BInf can have many implementations, and the method should work for all of them, not just one.

Always bear in mind that extending a class or implementing an interface defines an is a relationship. All the rules of widening/narrowing are logical consequences of this.

It's easier if you imagine it with a specific example: money. Coins are money and notes are money too.

If you go to a shop which decided to restrict the change they give you from your purchase to coins, it may be annoying but it's legal. It's fine because it doesn't break the contract, they are always returning money.

But when you're in a shop where they're supposed to accept money and they won't accept your coins, that's not okay.

• Ismar Slomic: Ok, I see your point. So what options do I have and whats the best practice for narrowing accepted types as parameter types in the implementation class AImpl for method doSomething3()? Creating separate Interface only for AImpl?
• biziclop: @IsmarSlomic Why do you want to narrow it?
• Joeri Hendrickx: if you need to do this, then you probably needed a generic interface.
• Ismar Slomic: @JoeriHendrickx: Ok, could you please give an example?
• Joeri Hendrickx: Define your interface as AInf<T extends BInf>, your method as void doSomething<T>. Then in your implementation, implement AInf<BImpl>. Then your signature will work, but you can only use your class at places where an AInf<BImpl> is expected. Which is okay, considering the use case.

Answer 2

You must have the same type as the interface.

The interface says it'll accept

void doSomething3(BInf param);

Which means it'll accept BInf and any subtype (because they can be expected to behave the same - see the Liskov Substitution Princple.

Your implementation doesn't obey this contract

public void doSomething3(BImpl param)

This implementation says I'll only work for BImpl, but says nothing about BInf.

(edit in response to question from @IsmerSlomic)

For return types, Java allows covariant return types. This doesn't break LSP because it returns something that guarantees to be at least the return type in the interface. If the return type is more specialized, then by LSP it'll still do the same thing as returning the original interface.

• Ismar Slomic: I see your point, but how does this principle differ when you use same thing for return type, see doSomething2()
• Xavier Portebois: @IsmarSlomic : for returned types, the interface AInf wants anything that fulfill the BInf contract, so BImpl works. Never forget: PECS (Produces=Extends, Consumes=Super). As a parameter, you must take the higher level specified by the interface in order to answer any possible call of the method, but as returned type, you can return anything that extends the interface (as your consumer will need at least the interface contract).

Answer 3

its declared as :

void doSomething3(BInf param);

but you try and implement with different type :

public void doSomething3(BImpl param)

Binf and BImpl

• Ismar Slomic: But BImpl is implementing the BInf, right. And this works as return type in doSomething2(), but not as parameter type. Why?

Answer 4

The issue is that doSomething3 is taking Bimpl as the parameter but the interface says the parameter is BInf (BImpl is not BInf). And since there is a @Override annotation, you are telling the compiler that you are overriding the method from interface, which you are clearly not and hence the error.

Answer 5

You can return AImpl and BImpl because they're covariant return types (or simply put, all AImpl objects are AInf objects, and all BImpl objects are BInf objects, so the caller knows it's getting back an AInf or BInf object as declared in the interface).

This doesn't work for method parameters though because you can't control what's passed to the doSomething3() method, so there's no guarantee that the BInf argument is actually a BImpl.