Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Blazkowicz, Вы писали:

B>Вот подумалось ещё чуток:

предыдущий вариант мне импонировал больше.
1) не нужно в каждом классе определять getKey(). Можно конечно сделать базовый класс, и в нем через рефлекшен определять значение поля, но такой вариант обязывает наследоватся от этого класса и вводит неявную зависимость родительского класса от поля в наследнике.
2) такой контракт ограничивает количество action-ов одного класса в системе, что не всегда удобно, так как часто лучше параметризировать некоторый инстанс класса, чем делать еще одного насденика.

Имеется

LinkedHashMap

, в которой храняться ключ и его параметры:

LinkedHashMap<String, ArrayList>

требуется реализовать вызов соответсвующих функций (имена пусть совпадают с ключем карты)
и параметры функции ArrayList, но требуется это организовать без использывания case структур
или каскадов if. Мне подсказали что это можно реализовать с помощью комманд паттерн. а как иммено?

Здравствуйте, Leeif, Вы писали:

L>требуется реализовать вызов соответсвующих функций (имена пусть совпадают с ключем карты)
L>и параметры функции ArrayList, но требуется это организовать без использывания case структур
L>или каскадов if. Мне подсказали что это можно реализовать с помощью комманд паттерн. а как иммено?

Как-то так.

public interface Action
{
     void doAction(List args) 
}

public class DoSomethingAction implements Action
{
     void doAction(List args)
     {
         //Do something
     } 
}

public class ActionBag
{
      static Map<String, Action> actionMap = new HashMap<String, Action>();
      static
      { 
           actionMap.put("Action Key", new DoSomethingAction());
      }

      public void doAction(String actionKey) 
      {
           Action action = actionMap.get(actionKey);
           action.doAction(getArguments(actionKey));
      }
}

Только вот Action/ActionBag практически во всех нужных Framework-ах уже существует. Редко приходится самому писать.

Здравствуйте, Blazkowicz, Вы писали:

Вот подумалось ещё чуток:

public interface Action
{
     void doAction(List args);
     String getKey(); 
}

public class DoSomethingAction implements Action
{
     static final String KEY = "DoSomethingAction.key"
     public void doAction(List args)
     {
         //Do something
     } 
     public String getKey()
     {
          return KEY;
     }
}

public class ActionBag
{
      static Map<String, Action> actionMap = new HashMap<String, Action>();

      static
      { 
           regiter(new DoSomethingAction());
      }

      static void regiter(Action action)
      {
           actionMap.put(action.getKey(), action);
      }      

      public void doAction(String actionKey) 
      {
           Action action = actionMap.get(actionKey);
           action.doAction(getArguments(actionKey));
      }
}

Здравствуйте, Lucker, Вы писали:

L>предыдущий вариант мне импонировал больше.
L>1) не нужно в каждом классе определять getKey(). Можно конечно сделать базовый класс, и в нем через рефлекшен определять значение поля, но такой вариант обязывает наследоватся от этого класса и вводит неявную зависимость родительского класса от поля в наследнике.

Хотелось инкапсулировать ключ в команде чтобы не складировать ключи где попало что в итоге приведет к их размазыванию по системе.
Регулярное переопределение этого метода конечно гемор, но он того стоит, ИМХО.

L>2) такой контракт ограничивает количество action-ов одного класса в системе, что не всегда удобно, так как часто лучше параметризировать некоторый инстанс класса, чем делать еще одного насденика.

Не понял. Это ты про AbstractAction или где?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Lucker, Вы писали:

B>Хотелось инкапсулировать ключ в команде чтобы не складировать ключи где попало что в итоге приведет к их размазыванию по системе.
B>Регулярное переопределение этого метода конечно гемор, но он того стоит, ИМХО.

Ну так а зачем размазовать? Если все делать "правильно", то ничге кроме как в конфиге этот ключ не должен появляться. Если надо на него сослаться — то делается это через логическое имя команды (типа String nextCommand), которому в конфиег присваевается правильное значение.

L>>2) такой контракт ограничивает количество action-ов одного класса в системе, что не всегда удобно, так как часто лучше параметризировать некоторый инстанс класса, чем делать еще одного насденика.

B>Не понял. Это ты про AbstractAction или где?

это я про то, что например объект класса DoSomethingAction может быть в баге только один. Если например DoSomethingAction имеет довольно сложную реализацию, и нужно иметь другую такую же реализацию но слегка измененую, до быват удобно просто добавить какой-нить параметр к классу типа boolean doSomethingElse, и анализировать его значение вместо выделения templateMethod-а и создания еще одного подкласса.

Здравствуйте, Lucker, Вы писали:

L>Ну так а зачем размазовать? Если все делать "правильно", то ничге кроме как в конфиге этот ключ не должен появляться. Если надо на него сослаться — то делается это через логическое имя команды (типа String nextCommand), которому в конфиег присваевается правильное значение.

Это верно для проекта функциональносьт которого определена. В растущем же проекте энтропия увеличивается.

L>>>2) такой контракт ограничивает количество action-ов одного класса в системе, что не всегда удобно, так как часто лучше параметризировать некоторый инстанс класса, чем делать еще одного насденика.

B>>Не понял. Это ты про AbstractAction или где?

L>это я про то, что например объект класса DoSomethingAction может быть в баге только один. Если например DoSomethingAction имеет довольно сложную реализацию, и нужно иметь другую такую же реализацию но слегка измененую, до быват удобно просто добавить какой-нить параметр к классу типа boolean doSomethingElse, и анализировать его значение вместо выделения templateMethod-а и создания еще одного подкласса.

Вообще я такие решения не очень люблю. Но не вижу где тут ограниченеия? Флаг про который ты говоришь может быть передан как в конструктор (тогда мы получим 2 инстанса одной команды но с разынми состояниями), либо вообще частью аргументов.