Здравствуйте, Hard_Club, Вы писали:
H_C>Если есть конструирование объекта с помощью вложенного switch с помощью анализа некоторых признаков, то каким паттерном проектирования / примитивом это можно перекрыть?
Command Map и ServiceLocator.
Если до этого условная логика использовалась для диспетчеризации запросов (по анализу некоторых признаков) и выполнения соответствующего действия (конструирование подходящего объекта), то нужно для каждого действия создать команду (шаблон Command), хранить команды в коллекции (Map), заменить условную логику кодом, выбирающим и выполняющим соответствующую команду (ServiceLocator выдаёт на выполнение команду, соответствующую "признакам").
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Hard_Club, Вы писали:
H_C>>Если есть конструирование объекта с помощью вложенного switch с помощью анализа некоторых признаков, то каким паттерном проектирования / примитивом это можно перекрыть?
ZEN>Command Map и ServiceLocator.
ZEN>Если до этого условная логика использовалась для диспетчеризации запросов (по анализу некоторых признаков) и выполнения соответствующего действия (конструирование подходящего объекта), то нужно для каждого действия создать команду (шаблон Command), хранить команды в коллекции (Map), заменить условную логику кодом, выбирающим и выполняющим соответствующую команду (ServiceLocator выдаёт на выполнение команду, соответствующую "признакам").
Это из области JEE, компонентов и вэб-фреймворков, как я понимаю, что не может квалифицироваться на решение столь простой проблемы тяжеловесным решением.
Здравствуйте, ZeroLatency, Вы писали:
ZL>Здравствуйте, iZEN, Вы писали:
ZEN>>Здравствуйте, Hard_Club, Вы писали:
H_C>>>Если есть конструирование объекта с помощью вложенного switch с помощью анализа некоторых признаков, то каким паттерном проектирования / примитивом это можно перекрыть?
ZEN>>Command Map и ServiceLocator.
ZEN>>Если до этого условная логика использовалась для диспетчеризации запросов (по анализу некоторых признаков) и выполнения соответствующего действия (конструирование подходящего объекта), то нужно для каждого действия создать команду (шаблон Command), хранить команды в коллекции (Map), заменить условную логику кодом, выбирающим и выполняющим соответствующую команду (ServiceLocator выдаёт на выполнение команду, соответствующую "признакам").
ZL>Это из области JEE, компонентов и вэб-фреймворков, как я понимаю, что не может квалифицироваться на решение столь простой проблемы тяжеловесным решением.
Это вообще к Java никак не относится.
У Джошуа Кириевски разве что в похожей комбинации отсутствует ServiceLocator. Но этот компонент я ввёл для специальной обработки многокритериального выбора от простой функции Map — выдачи объекта по ключу. Нужный ключ к Map должен сформировать ServiceLocator, исходя из признаков, предъявляемых пользователем, и поставить действительно нужный объект.
ZL>>Это из области JEE, компонентов и вэб-фреймворков, как я понимаю, что не может квалифицироваться на решение столь простой проблемы тяжеловесным решением.
ZEN>Это вообще к Java никак не относится.
ZEN>У Джошуа Кириевски разве что в похожей комбинации отсутствует ServiceLocator. Но этот компонент я ввёл для специальной обработки многокритериального выбора от простой функции Map — выдачи объекта по ключу. Нужный ключ к Map должен сформировать ServiceLocator, исходя из признаков, предъявляемых пользователем, и поставить действительно нужный объект.
У этого Джошуа — ServiceLocator + Command.
Здесь в других ветках предлагалось — State или Strategy/Factory + FactoryRepository
Здравствуйте, Hard_Club, Вы писали:
H_C>Если есть конструирование объекта с помощью вложенного switch с помощью анализа некоторых признаков, то каким паттерном проектирования / примитивом это можно перекрыть?
Здравствуйте, TarasB, Вы писали:
TB>Здравствуйте, Hard_Club, Вы писали:
H_C>>Если есть конструирование объекта с помощью вложенного switch с помощью анализа некоторых признаков, то каким паттерном проектирования / примитивом это можно перекрыть?
TB>А надо ли?
Если SWITCH — большой, то, в принципе, не помешает: ведь анализируется всего один параметр и принимается решение как конструировать, если всё это распихать по Command Map/Command патернам с правильно названными классами, будет читаться нормально.
Но это — простой и понятный случай, в SWITCH один параметр. Вот мне бы интересно мнение сообщества если здесь бы был не SWITCH а несколько экранов IF'ов где анализируются несколько параметров и в ветках по разному конструируется один и тот же объект.
Как определить ту границу когда стоит оставить метод с IF'ами где, в принципе, логика собрана в одном месте, либо раскидать эту логику по разным классам следуя каким-либо паттернам? Кто что думает?
Здравствуйте, Antei, Вы писали:
A>Но это — простой и понятный случай, в SWITCH один параметр. Вот мне бы интересно мнение сообщества если здесь бы был не SWITCH а несколько экранов IF'ов где анализируются несколько параметров и в ветках по разному конструируется один и тот же объект. A>Как определить ту границу когда стоит оставить метод с IF'ами где, в принципе, логика собрана в одном месте, либо раскидать эту логику по разным классам следуя каким-либо паттернам? Кто что думает?
Универсальных рецептов нет. Это то, что по модному именуется "common sense".
