Java Interface-Implementation Pair [closed]

Answer 1

Static implementations have two problems:

• you can't really find them with any static code analysis, like listing all the implementors, because the static method does not implement the interface, so you're forced to mention the default implementation in the javadoc

• there's sometimes the need to have some state in the implementor, which cannot really be done within a static method

I thus prefer to use a concrete class which allows for both inheritance (if you're not limited by single inheritance) and composition, and call the resulting class *Peer, as it will normally be use with alongside the main class implementing the interface. The peer will implement the interface, and may also have a reference to the main object in case it needs to fire events in the name of the main class.

Answer 2

Composition trumps multiple inheritance in terms of flexibility. As with the Adapter Pattern (see the GOF book), it clearly allows us to adapt (morph) classes to different behaviors depending on callers request. See the IAdaptable interface in Eclipse RCP. Basically using interfaces is the same as using the Adapter Pattern built in in the Java language directly. But using adaptable classes is better than implementing multiple interfaces. Adaptable classes are more flexible, but they have some CPU overhead: the instanceof operator consumes less CPU than calling canAdapt(Class clazz). But in modern JVMs this could be false, since calculating instanceof with interfaces is more complex than calculating instanceof with inheritance.

Answer 3

I'd also use static methods to declare default functionality for stateless functionality.

For stateful functionality I'd prefer composition instead of inheritance. With composition and using delegates/adapters you can combine default functionality from many sources.

e.g.

public interface StuffDoer{
    void doStuff();
    void doOtherStuff();
}

public class MyStuffDoer implements StuffDoer{
    private final StuffDoer mixin;
    public  MyStuffDoer(StuffDoer mixin){
        this.mixin = mixin;
    }
    public void doStuff(){
        mixin.doStuff();
    }
    public void doOtherStuff(){
        mixin.doOtherStuff();
    }

}

public class MyStuffDoer2 implements StuffDoer{
    private final StuffDoer mixin1, mixin2;
    public  MyStuffDoer(StuffDoer mixin1, StuffDoer mixin2){
        this.mixin1 = mixin1;
        this.mixin2 = mixin2;
    }
    public void doStuff(){
        mixin1.doStuff();
    }
    public void doOtherStuff(){
        mixin2.doOtherStuff();
    }

}

For simple cases inheritance is ok as well, but it is not really very flexible.

Implementing multiple interfaces is also a case where this approach scales better.

public interface A{
    void doStuff();
}

public interface B{
    void doOtherStuff();
}

public class MyStuffDoer implements A, B{
    private final A mixin1;
    private final B mixin2;
    public  MyStuffDoer(A mixin1, B mixin2){
        this.mixin1 = mixin1;
        this.mixin2 = mixin2;
    }
    public void doStuff(){
        mixin1.doStuff();
    }
    public void doOtherStuff(){
        mixin2.doOtherStuff();
    }
}

You can't do this with abstract classes. I have used this composition approach on a few projects, and it worked quite fine.

Answer 4

Now that Java 8 is out, this pattern is much nicer:

public interface StuffDoer{
    default void doStuff() {
        dosomestuff...
    }
}

public class MyClass implements StuffDoer {
    // doStuff automatically defined
}

Lambda got all the attention, but this was the most tangible benefit of Java 8 for our company. Our inheritance hierarchies got a lot simpler when we no longer needed to have abstract classes just to have default method implementations.