Java Interface-Implementation Pair

Question

Is there a preferred method or style of creating a default implementation for interface methods? Suppose I had a commonly used interface where in 90% of the cases the functionality I wanted was identical.

My first instinct is to create a concrete class with static methods. I would then delegate the functionality to the static methods when I want the default functionality.

Here is a simple example:

Interface

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

Concrete Implementation of methods

public class ConcreteStuffDoer{
    public static void  doStuff(){
        dosomestuff...
    }
}

Concrete Implementation using defualt functionality

public class MyClass implements StuffDoer{
    public void  doStuff(){
        ConcreteSuffDoer.doStuff();        
    } 
}

Is there a better approach here?

EDIT

After seeing a few of the proposed solutions I think I should be more clear about my intent. Essentially I am trying to work around Java not allowing multiple inheritance. Also to be clear I am not trying to make a statement about whether or not Java should allow multiple inheritance. I am just looking for the best way to create a default method implementation for classes implementing an interface.

Answer 1

You could turn the interface into an abstract class, and provide default implementation for the methods as appropriate.

Update: I see, the multiple inheritance closes out changing the interface into an abstract class... in this case I would do the same as you. If the default implementation of the method(s) is not state-dependent, the best place for them is indeed in a static utility class. However, if there is state involved, I would consider object composition, which could even end up as something like a Decorator.

Answer 2

I follow more or less the pattern I initially learned from Swing. I have an interface then I create either a "Base" or an "Adapter" class. For me, an adapter will often have do-nothing implementations for all of the interface methods, to allow an implementor to write just the methods they need while ignoring the others. A base will be an abstract class that provides convenient implementations for some of the interface methods - hopefully the "most likely" implementation.

For example, I have a SearchFilter interface that, among other things, has an apply(Collection<T>) method. That method will almost always loop through the collection and call the interface method boolean include(T item) to decide whether or not to keep or filter out the item. My SearchFilterBase provides that as an implementation for apply() and an implementor only has to write their include() logic.

Implementors are free, of course, to simply implement the whole interface themselves and not derive from the Base, which is the advantage over changing the interface to an abstract class, which forces them to use their single inheritance (This is the problem with java.util.Observable)

---

In response to N8g's comment - You can subclass the base or adapter but are not required to subclass -- you can implement the interface yourself from scratch. The base or adapter is provided as a convenience, implementing no-op methods so you don't have to do it, or implementing convenient common functionality in an abstract base class (like my SearchFilterBase class). The advantage this has over turning the interface into an abstract class is that you don't force inheritance from your abstract class.

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

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 5

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 6

This is the approach I would take:

public interface MyInterface {

      MyInterface DEFAULT = new MyDefaultImplementation();

      public static class MyDefaultImplemenation implements MyInterface {
      }
 }

Of course, the MyDefaultImplementation may need to be private, or its own top level class, depending on what makes sense.

You can then have the following in your implementations:

 public class MyClass implements MyInterface {
        @Override
        public int someInterfaceMethod(String param) {
             return DEFAULT.someInterfaceMethod(param);
        }
  }

Its a bit more self-documenting, and ultimately more flexible, than a default implementation class that exists elsewhere but is not referenced by the interface. With this you can do things like just pass the default implementation as a method parameter when required (which you cannot do with the static methods).

Of course, the above only works if there is no state involved.

Answer 7

Most of the time, I go with something like this:

public interface Something {
  public void doSomething();

  public static class Static {
    public static void doSomething(Something self) {
      // default implementation of doSomething()
      // the name of the method is often the same
      // the arguments might differ, so state can be passed
    }
  }

  public static abstract class Abstract implements Something {
    // the default abstract implementation
  }

  public static class Default extends Abstract {
    // the default implementation
    public void doSomething() {
      Static.doSomething(this);
    }
  }

  public static interface Builder extends Provider<Something> {
    // initializes the object
  }
}

I tend to use inner classes because these classes are really related, but you may also use regular classes.

Also, you might want to put the utility class (Static) in a separate file if the methods don't only concern the interface.

---

By the way, the problem with decorators is that they hide other implemented interfaces. In other words, if you have a something decorator the following is false new SomethingDecorator(new ArrayList<Object>()) instanceof List<?> if SomethingDecorator does not implement the interface of lists. You can work arround using reflection API and in particular using a Proxy.

Another good aproach are adaptors, as pointed by PersicsB.

Answer 8

Dependency injection could provide the delegate, and specify a default implementation -- which could be overridden in unit tests.

For example, the Guice framework supports an annotation on the interface for its default implementation, which can be overridden by an explicit binding in unit tests.

@ImplementedBy( ConcreteStuffDoer.class )
public interface StuffDoer{
    void doStuff();
}

public class ConcreteStuffDoer implements StuffDoer {
    public void  doStuff(){ ... }
}

public class MyClass implements StuffDoer{
  @Inject StuffDoer m_delegate;
  public void  doStuff(){ m_delegate.doStuff(); }
}

This does introduce the requirement that creating an instance of MyClass requires a Guice method rather than simply new.

Answer 9

If it your whatever function :-) works as a static then you don't need to delegate to it all since that means it doesn't need "this" - it's a utility function.

You can re-examine whether you really have overwhelming reason not to merge whatever you consider default implementations into the first abstract class that implements that interface - you know, the adaptation to reality :-)

Also, you can create secondary, protected virtual methods in abstract class that your interface-derived methods are going to call which giver you more control i.e. deriving class doesn't have to replace the methods and copy&paste 90% of it's code - it can just override a method that gets called from the main methods. Gives you a degree of behavioral inheritance.