Java Interface-Implementation Pair [closed]

Answer 1

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 2

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 3

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.

Answer 4

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 5

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 6

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.