使用空方法的默认实现的设计模式

Question

是否存在特定的设计模式来描述提供非抽象默认实现的场景，该默认实现使用空的NO-OP实现来实现接口上的全部或部分方法。 这样做的目的是减轻子类实现它们自己可能不需要/使用的方法的负担：

public interface MyInterface {
    public void doThis();
    public void doThat();
    public void done();
}

public class MyClass implements MyInterface {
    public void doThis() {
        // NO-OP
    }
    public void doThat() {
        // NO-OP
    }
    public void done() {
        // Some standard implementation
    }
}

public class MuSubClass extends MyClass {
    public void doThat() {
        // Subclass only cares about doThat()
    }
}

我已经看到这种模式使用了很多次，包括 SAX 框架中的 Java DefaultHandler 和 MouseAdapter。 在某些情况下，此类类被命名为适配器，但我的印象是适配器模式在两个不同的接口之间进行转换。

鉴于在这些情况下，只有一个声明的接口被转换为该接口的未定义子集 - 我不清楚这如何符合适配器模式的精神。

此外，鉴于某些方法，我不太明白这是如何遵循 NullObject 模式可以有一个实现，并且 NullObject 传统上是一个单例。

Answer 1

您应该遵循不同的设计原则：接口隔离原则

接口隔离原则指出，不应强迫客户端实现他们不使用的接口。 与一个胖接口不同，许多基于方法组的小接口是首选，每个方法服务一个子模块。

您不应该实现 MORE 并且您不应该实现 LESS

查看相关的 SE 问题以了解更多详细信息。

接口隔离原则

接口隔离原则-编程到接口

Answer 2

我在 spring 中看到过这种设计，其中有一个名为 FlowExecutionListenerAdapter 可以帮助您实现所有 FlowExecutionListener 操作。

然而，它听起来也确实像空对象模式。 然而，我觉得它在适配器世界中表现得更好，纯粹是因为它改变了接口的行为，只允许你实现你想要的部分......但它是一个艰难的过程。

我确定这个问题以前有人问过吗？

这听起来类似不是吗？ 可能值得一读。

Answer 3

它也用在 Swing 中（WindowAdapter，它实现了 WindowListener）。 它只是一个方便的适配器，您只需以这种方式定义 1-2 个方法即可拥有一个有用的窗口侦听器。 这确实是Adapter模式的一个实例，也显示了抽象类的强大功能。 它甚至是一个例子来说明为什么多重实现继承有时是有用的。

对于常规设计模式，在模板方法中您可以定义钩子操作，这些操作可以被重写（与抽象方法不同，抽象方法必须被重写），但默认行为（通常是 NO-OP）也有意义。

Answer 4

很好的问题。

我已经开始使用 NoOp 作为此模式的类名前缀。 它简短、清晰且不过载（例如 Empty [不包含任何内容？]、Null [空对象模式，有什么不同吗？]、Abstract [它提供一些实现吗？]，或Base [它提供一些实现吗？]）。

当我有一个第三方 API 来为复杂操作期间的仪器提供“钩子”时，我可能会编写这种风格的类。 考虑库提供的以下两个类：

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();
}

在这种情况下，您可以使用如下模式来纠正一个类：

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 5

这种模式在旧版本的 Java 中很流行。 它是 Java 7 的默认替代方案接口中的方法。

Josh Bloch 将其称为骨架实现。 虽然骨架实现通常是抽象的，但如果骨架本身就足够了，则无需强制客户端创建子类。

我同意之前的回答，指出了接口隔离原则。 对骨架实现的需求可能是一种代码味道，表明接口太“胖”并且可能试图做不止一项工作。 在这种情况下，拆分接口比使用虚拟或 noop 逻辑创建骨架实现更好。

Answer 6

对我来说，这似乎最接近 特殊情况 或 空对象模式。

您的更新建议类似于 模板方法 期望您没有一个调用的方法每个模板方法例如

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

Answer 7

您是否在询问空对象模式？

根据您的编辑，MyClass 对象只不过是默认实现。 我认为没有任何特定的设计模式可以描述它。

Answer 8

我相信 Martin Fowler 会将此称为空对象模式。 在他的《重构》一书中[1]，Martin 介绍了空对象：

多态的本质是，不问对象做什么
输入它是，然后根据答案调用一些行为，你
只需调用该行为即可。 该对象根据其类型执行以下操作：
正确的事。 执行此操作不太直观的地方之一是您
字段中有空值。

他后来补充道，“当许多客户想要做同样的事情时，你会受益；他们可以简单地依赖默认的 null 行为。” 他还为需要不同行为的客户端引入了 isNull() 方法。

我同意我有时会看到一种称为适配器的（通常是抽象的）实现。 例如Android框架中 AnimatorListenerAdapter （源码此处）描述为：

此适配器类提供 Animator.AnimatorListener 方法的空实现。 任何只关心此侦听器的方法子集的自定义侦听器都可以简单地子类化此适配器类，而不是直接实现接口。

[1] “重构：改进现有代码的设计”，第 9 章，“简化条件表达式”，“引入 Null 对象”。

Answer 9

没有默认实现的设计模式。

我通常在类名称后面附加 DoNothing 前缀。 根据其意图，我还使用 Base 或 Default （后者被广泛使用）。 也许 MouseAdapter 应该被称为 DefaultMouseListener。

在您关心的情况下，您可以使用简单的 DynamicProxy，您必须仅返回一个“好的”默认值（对象为 null，数字为 0 等）。

顺便说一句，这是一个非常好的问题。

编辑

此外，这既不是 存根 也不是 Mock：也许它可能与 Stub 混淆，但意图不同。