защищенное поле против защищенного метода против реализации интерфейса для обработчиков действий - PullRequest
Новая
       12

защищенное поле против защищенного метода против реализации интерфейса для обработчиков действий

3 голосов
/ 20 июля 2010

У меня есть класс, который представляет базовую страницу с кнопками «вернуться назад», «перейти вперед» и «canel» в Wicket.Но не на всех страницах есть все кнопки, например, на первой странице явно нет «возврата».

Моя идея - определить универсальный ActionHandler 

public interface ActionHandler {
  void perform();
}

и позволить возврату подклассовподдерживаемые ими действия: 

public Derived extends BasicPage {
  protected ActionHandler getForwardHandler() {
    return new ActionHandler() {
      void perform() {
        doIt();
      }
    };
  }
}

Вопрос: почему бы не использовать защищенные поля? 

public Derived extends BasicPage {
  protected forwardHandler = new ActionHandler() {
      void perform() {
        doIt();
      }
    };
}

Другой вариант - не использовать наследование (что на самом деле не имеет смысла).здесь) и установите ActionHandlers извне: 

Toolbar toolbar = new Toolbar();
toolbar.setForwardHandler(new ActionHandler() {
  void perform() {
    doIt();
  }
});

Причина, по которой я не использую интерфейсы, такие как ForwardHandler и CancelHandler, заключается в том, что я хочу передать обработчик на панель инструментов, что делает ActionHandlers какпараметры.Или вы бы передали всю страницу на панель инструментов и позволили панели инструментов решать, какие кнопки отображать в зависимости от реализованных интерфейсов?Для меня это звучит как плохой ООП.

Идея состоит в том, что не каждая страница должна определять новую панель инструментов, но, возможно, это будет проще ...

1 Ответ

2 голосов
/ 20 июля 2010

Почему бы не использовать защищенное поле?Это будет работать;подклассы просто переназначают поле желаемым ActionHandler.

Однако я думаю, что это хуже, чем защищенный метод.Вы пытаетесь определить поведение, а поведение определяется методами.С полем вы либо присваиваете его начальное значение null, либо некоторому фиктивному обработчику, который оставляет объект в странном состоянии, в котором поведение, которое должно быть внутренне определено объектом, может быть случайно оставлено неопределенным.

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

Я не знаю, имеет ли смысл для конкретных подклассов определять свое поведение вызывающей стороной.Если FooPage действительно представляет страницу Foo, а Foo имеет фиксированное поведение, то FooPage должен определить это.

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

...