这个模式/习语是什么？有什么福利待遇？

Question

在我工作的代码库中，我经常看到这个成语，本质上是：

接口->抽象类，定义getter/setters ->实现

例如：

interface Foo{
    void doSomethingA();
    void doSomethingB();
}

abstract class AbstractFoo implements Foo{
    protected int x;
    protected String y;
    int getX(){ return x;}
    void setX(int x){ this.x = x;}
    String getY(){ return y;}
    void setY(String y){ this.y = y;}
}
//One or more concrete classes extending AbstractFoo

这个有名字吗？我看到的唯一好处是扩展AbstractFoo的类不需要重新实现它们的getter和setter。

Answer 1

这不是设计模式。

接口是显而易见的:每个实现接口的类都必须实现它的方法--不问任何问题。

如果抽象类愿意，它可以为每个方法提供默认行为。因此，是的，这是为了方便子类开发人员。请记住，编写抽象类的人很可能至少提供一个具体的子类，因此他们会从中获益。

Getter和setter不是重点。任何好的IDE都可以为您生成它们。对于复杂的默认行为，该特性更有意义。

看看约书亚·布洛赫在设计集合API时是如何在java.util包中使用这个成语来取得巨大成功的。

Answer 2

我认为它的名字是“抽象实现”。您不只是将getter和setter放入抽象类，而是将接口的所有实现都可能具有相同之处。这样做的目的是通过预先处理常见的内容来更容易地提供接口的实现。如果实现者想以一种完全不同的方式实现这些东西，他们可能仍然选择不扩展抽象基类。