Это вариация шаблона декоратора или шаблон вообще? - PullRequest
0 голосов
/ 05 октября 2011

Ниже приведена упрощенная версия кода, который я написал для переопределения метода класса (используя композицию), в этом случае имя метода, которое я переопределяю, это addbuttons (); Класс «Экран» добавляет кнопки на экран, тогда как класс «Подэкран» добавляет пользовательские кнопки к экземпляру Экран. Может быть, это не пример шаблона декоратора, поскольку я переопределяю функциональность, а не расширяю ее? Есть ли лучший способ (используя шаблон проектирования?) Для достижения той же функциональности?

public class Driver {

    public static void main(String args[]){
        AddComponents add1 = new Screen();
        add1.addButtons();

        Screen newScreen = new Screen();
        AddComponents add2 = new SubScreen(newScreen);
        add2.addButtons();
    }

}
    public interface AddComponents {

         public void addButtons();
        }

public class Screen implements AddComponents{

    public void addButtons() {
        //Add Buttons to screen class
    }

}
public class SubScreen implements AddComponents{

    private Screen screen;

    public SubScreen(Screen screen){
        this.screen = screen;
    }

    public void addButtons() {
        //add different custom buttons to Screen class
    }

}

1 Ответ

3 голосов
/ 06 октября 2011

Другой возможностью было бы назвать его Proxy . Decorator и Proxy технически очень похожи - в большинстве случаев разница не техническая, а основанная на намерении.Ваш пример немного минимален, и поэтому трудно угадать намерение.

Редактировать

На детальном уровне: Screen и SubScreen doне делиться кодом.Если вы начнете добавлять методы к обеим реализациям и общему интерфейсу AddComponents, вы можете обнаружить

  • , что вам необходимо продублировать код как в Screen, так и в SubScreen (или делегировать Screen) и
  • что вы должны добавить методы к AddComponents, которые делают этот интерфейс плохо названным.

Если оба класса экрана похожи, оба на абстрактном логическом уровне и на уровне реализации тогда класс AbstractScreen с двумя производными классами будет лучше.Чтобы вернуть образец речи: используйте Factory Method в AbstractScreen, чтобы специализировать поведение различных кнопок.

В вашем текущем коде есть одна странная вещь: почему существует методaddButton определены в любом случае?Просто добавьте кнопки в соответствующий конструктор, так как в любом случае пользователь должен вызвать addButtons, а у метода нет аргументов.

Еще один не объясненный момент заключается в следующем: SubScreen имеет ссылку на Screen который не используется.Зачем?Будет ли больше методов во всех участвующих классах Screen, SubScreen и AddComponents?Будет ли каждый метод иметь SubScreen делегат для Screen или только половину из них?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...