Design pattern for default implementation with empty methods

Question

Is there a specific design pattern that describes the scenario where a non-abstract default implementation is provided that implements all or some of the method

Answer 1

There are no design patterns for default implementation.

I usually append DoNothing prefix to the name of class. Depending on it's intent I use also Base or Default (the latter is widely used). Probably MouseAdapter should be called DefaultMouseListener.

In the case you care, you can stub systematically an interface with a simple DynamicProxy, you must return only a "nice" default value (null for Object, 0 for numeric, etc).

BTW this is a very good question.

EDIT

Furthermore this is neither a Stub or a Mock: maybe it can be confused with a Stub but the intent is different.

Answer 2

I believe Martin Fowler would call this a null object pattern. In his Refactoring book[1], Martin introduces null objects as such:

The essence of polymorphism is that instead of asking an object what type it is and then invoking some behavior based on the answer, you just invoke the behavior. The object, depending on its type, does the right thing. One of the less intuitive places to do this is where you have a null value in a field.

He later adds, "You benefit when many clients want to do the same thing; they can simply rely on the default null behavior." He also introduces an isNull() method for clients requiring variant behaviors.

I would agree that I sometimes see a (often abstract) implementation called an adapter. For example, in the Android framework, AnimatorListenerAdapter (source code here) is described as:

This adapter class provides empty implementations of the methods from Animator.AnimatorListener. Any custom listener that cares only about a subset of the methods of this listener can simply subclass this adapter class instead of implementing the interface directly.

[1] "Refactoring: Improving the Design of Existing Code," Chapter 9, "Simplifying Conditional Expressions," "Introduce Null Object."

Answer 3

Great question.

I have started using NoOp as a class name prefix for this pattern. It's short, clear, and not overloaded (like Empty [contains nothing?], Null [Null Object pattern, which is different?], Abstract [Does it provide some implementation?], or Base [Does it provide some implementation?]).

I may write this style of class when I have a third-party API which provides "Hooks" for isntrumentation during a complex operation. Consider the following two classes provided by a library:

public class LongRunningActionRunner {
    public void runSomethingLong(DecisionListener cdh) {
        // ...
    }
}

public interface DecisionListener {
    public void beforeFooHook();
    public void afterFooHook();
    public void beforeBarHook();
    public void afterBarHook();
    public void beforeBazHook();
    public void afterBazHook();
}

In this case, you might right a class using this pattern like this:

public class NoOpDecisionListener implements DecisionListener {
    @Override public Something beforeFooHook() {}
    @Override public Something afterFooHook() {}
    @Override public Something beforeBarHook() {}
    @Override public Something afterBarHook() {}
    @Override public Something beforeBazHook() {}
    @Override public Something afterBazHook() {}
}

Answer 4

To me this seems closest to the Special Case or Null Object pattern.

Your updates suggest something similar to Template Method expect that you don't have a single method that calls each template method e.g.

public void doEverything()
{
  doThis();
  doThat();
  done();
}

Answer 5

Are you asking about the Null Object Pattern?

Further to your edit, the MyClass object is nothing more than a default implemenation. I don't think there's any particular design pattern that describes it.

Answer 6

This pattern was prevalent in older versions of Java. It is the Java 7 alternative to default methods in interfaces.

Josh Bloch calls it a skeletal implementation. While a skeletal implementation is typically abstract, you needn't force clients to create a subclass if the skeleton itself is sufficient.

I agree with the previous answer pointing out the Interface Segregation Principle. The need for a skeletal implementation can be a code smell indicating an interface is too "fat" and may be trying to do more than one job. Splitting up the interface is preferable in this scenario to creating a skeletal implementation with dummy or noop logic.