CODEWITHSUNDEEP
java
Ismar Slomic
Ismar Slomic

Reputation: 5514

Use of interface as parameter type in java

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
{

}

Upvotes: 1

Views: 2378

Answers (5)

Jeff Foster
Jeff Foster

Reputation: 44706

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.

Upvotes: 3

biziclop
biziclop

Reputation: 49734

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.

Upvotes: 3

Emerson Farrugia
Emerson Farrugia

Reputation: 11353

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.

Upvotes: 0

Aravind Yarram
Aravind Yarram

Reputation: 80176

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.

Upvotes: 0

NimChimpsky
NimChimpsky

Reputation: 47280

its declared as :

void doSomething3(BInf param);

but you try and implement with different type :

public void doSomething3(BImpl param)

Binf and BImpl

Upvotes: 0

Related Questions