javainheritanceinterfaceabstract-class

Java Interface Contracts Issue


I am having an interface called I. This interface is implemented by an abstract class AClazz.

AClazz implements I

Now this abstract class is extended by several concrete classes.

ConcreteClazz extends AClazz
AnotherConcreteClazz extends AClazz

Now when I add a new method contract to the interface I why does eclipse and hence Java language complain about a missing implementation inside the concrete classes (ConcreteClazz and AnotherConcreteClazz) and not inside the abstract class AClazz?

If AClazz was a concrete class (& not abstract) and the concrete classes extended from the non abstract AClazz will Java complain about missing implementation inside concrete classes again?


Solution

  • So say your interface I has a method m:

    public interface I {
         public void m (int someParameter);
    }
    

    Now AClazz implements I, and ConcreteClazz extends AClazz. That means that ConcreteClazz also implements I, whether or not you say so explicitly in the class declaration of ConcreteClazz. That means you can use a ConcreteClazz object anywhere an I is expected. So say somewhere, in some other class, you have a method

    void takeSomeAction(Something x, I y) {
        ....
        y.m (x.getSomeProperty());  // call the interface method
        ....
    }
    

    You can call it with a ConcreteClazz object:

    ConcreteClazz z = new ConcreteClazz(...);
    Something st;
    
    foo.takeSomeAction(st, z);
    

    You're giving takeSomeAction a ConcreteClazz to use as its I parameter. Then takeSomeAction will call the m method. How can this work unless you've provided an implementation for m, somewhere?

    That's why you need to implement m, either in AClazz or ConcreteClazz. You could implement it in AClazz, if that's the right thing to do, and then you don't need to provide another implementation in ConcreteClazz. But if you don't implement it in AClazz, it won't cause any errors, since, at runtime, you can't actually have an object of type AClazz. But since you can have objects of type ConcreteClazz, that means that somewhere, for ConcreteClazz, there has to be an implementation of m.