Question

我在我工作的代码库中看到了很多这样的习惯用法，基本上是：

界面 - ＆gt;定义getter / setter的抽象类 - ＆gt;实现

例如：

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

它不是设计模式。

接口很明显：实现接口的每个类都必须实现其方法 - 没有问题。

如果愿意，抽象类可以为每个方法提供默认行为。所以，是的，这是为了方便子类开发人员。请记住，编写抽象类的人可能至少提供一个具体的子类，因此会给他们带来好处。

吸气剂和制定者不是重点。任何好的IDE都可以为您生成它们。该功能对于复杂的默认行为更有意义。

看看Joshua Bloch在设计Collection API时如何在java.util包中使用这个成语取得巨大成功。

Answer 2

我认为它的名称是“抽象实现”。您不仅可以将getter和setter放入抽象类中，而且还可以将接口的所有实现都放在一起。我们的想法是通过提前处理常见的东西，更容易提供界面的实现。如果想要以完全不同的方式实现内容，实现者可能仍然选择不扩展抽象基类。

这种模式/习语是什么？有什么好处？

2 个答案: