Java MVC + вето / отложенное свойство - PullRequest
0 голосов
/ 07 октября 2010

У меня есть интерфейс FooModel и класс DefaultFooModel, которые имеют несколько простых свойств. Я застреваю в свойстве boolean enable, потому что хочу, чтобы это было вето / отложено:

public interface FooModel {
   public boolean isEnabled();
   /** returns old value */
   public boolean setEnable(boolean enable); 

   public void addFooListener(FooModel.Listener listener);
   public void removeFooListener(FooModel.Listener listener);

   public interface Listener {
      public void onFooEnableUpdate(boolean newEnable, boolean oldEnable);
   }
}

Я хочу, чтобы модель M была центральной точкой доступа для свойства enable. Но вот последовательность событий, которые я хочу, чтобы произошли:

  1. view V (или любой пользователь модели M) вызывает FooModel.setEnable(enable) в произвольном потоке.
  2. FooModel может:

    а. немедленно вызвать onFooEnableUpdate(newEnable, oldEnable) для каждого из слушателей в произвольном порядке

    б. запустить потенциально длинную последовательность событий, в результате чего другой объект (например, контроллер C) может решить, следует ли включить, и каким-то образом сообщить FooModel, в результате чего свойство enable может быть обновлено, и затем мы продолжим как обычно в (a) выше.

Дело в том, что я не уверен, как это сделать.

Подход 1: механизм для этого не должен быть частью интерфейса модели. Вместо этого у моего DefaultFooModel есть реализация, которая принимает FooController:

public interface FooController {
   public void onFooEnableRequest(boolean newEnable, boolean oldEnable);
}

Когда вызывается DefaultFooModel.setEnable(), он вызывает FooController.onFooEnableRequest(). Ожидается, что контроллер вернется немедленно, но может занять некоторое время, чтобы обработать запрос, а затем позже вызвать DefaultFooModel.updateEnable(), что вызовет реальный onFooEnableUpdate().

Подход 2: встроить что-то в интерфейс FooModel, но я не уверен, что.

Подход 3: Не встраивайте ничего в FooModel, просто сделайте так, чтобы он обрабатывал обычное свойство. Вместо этого Контроллер прослушивает FooModel.onFooEnableUpdate () и сразу переопределяет setEnable к старому значению, а затем вызывает FooModel.setEnable (), чтобы установить новое значение.

Любой совет?

1 Ответ

0 голосов
/ 07 октября 2010

Сделать FooModel классом вместо интерфейса.

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

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

  • notifyListeners(boolean newEnable, boolean oldEnable) уведомляет всех слушателей по умолчанию, вызывая следующий метод, но может быть переопределен, чтобы ничего не делать, или для условного уведомления
  • notifyListener(Listener listener, boolean newEnable, boolean oldEnable) уведомляет конкретного слушателя
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...