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

Question

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

接口 - >定义getter/setter的抽象类 - >实现

例如:

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在java.util设计Collection API时如何使用这个成语在包中取得巨大成功.