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

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

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

Например:

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


java design-patterns idioms
person TDJoe    schedule 24.02.2012    source источник
comment
Возможно наследование и абстракция от Foo?   -  person sll    schedule 24.02.2012

Ответы (2)


arrow_upward
6
arrow_downward

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

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

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

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

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

person duffymo    schedule 24.02.2012

arrow_upward
0
arrow_downward

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

person drmirror    schedule 24.02.2012