Что это за образец / идиома?Каковы преимущества?

Question

Я часто вижу эту идиому в кодовой базе, в которой я работаю, а именно:

Интерфейс -> Абстрактный класс, который определяет методы получения / установки -> Реализации

Например:

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, не нужно повторно реализовывать свои методы получения и установки.

Answer 1

Это , а не шаблон проектирования.

Интерфейс очевиден: каждый класс, реализующий интерфейс, должен реализовывать свои методы - без вопросов.

АннотацияКласс может обеспечить поведение по умолчанию для каждого метода, если пожелает.Так что да, это для удобства разработчиков подкласса.Помните, что тот, кто пишет абстрактный класс, скорее всего, предоставит хотя бы один конкретный подкласс, поэтому преимущества ему накапливаются.

Методы получения и установки не имеют значения.Любая хорошая IDE может сгенерировать их для вас.Эта функция более понятна для сложного поведения по умолчанию.

Посмотрите, как Джошуа Блох с большим успехом использовал эту идиому в пакете java.util, когда разрабатывал Collection API.

Answer 2

Я думаю, что он называется «Абстрактная реализация». Вы бы не просто помещали геттеры и сеттеры в абстрактный класс, но что-нибудь, что, скорее всего, имело бы все реализации интерфейса. Идея состоит в том, чтобы упростить предоставление реализаций интерфейса, заранее позаботившись об общих вещах. Разработчики могут по-прежнему хотеть не расширять абстрактный базовый класс, если они хотят реализовать вещи совершенно другим способом.