Дилемма выбора шаблона дизайна

Question

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

1. Контроллер звонков MasterJuicer.juice(List<Fruit> fruits). MasterJuicer в свою очередь вызывает CitrusJuicer.juice(fruits) и PulpyJuicer.juice(fruits).
2. Цепь ответственности не кажется правильной. Заказ, в котором соковыжималки называются, не имеет значения.
3. Фабрика? Контроллер звонит JuicerFactory.getJuicers(List<Fruit> fruits), чтобы получить List<Juicer>. Затем контроллер перебирается через каждый соковыжималка и звонит Juicer.juice(fruits). Обычна ли фабрика возвращать список экземпляров?
4. Поддержание реестра фруктов против соковыжималки в Map? Контроллер вызывает FruitsRegistry.getJuicer(Fruit fruit) для каждого фрукта, затем называет каждый соковыжималку в цикле.

Answer 1

Завод может предоставить правильные соковыжималки, но тогда ваша логика обработки соковыжималки будет нажата на ваш контроллер.

А combination моделей composite и visitor могут быть вам полезны.

1. Композитная модель позволит построить MasterJuicer, который знает о других соковыжималок и может инициировать процесс «Juicing» путем передачи в соковыжималки. Это касается «структурного» аспекта вашей проблемы.
2. Шаблон посетителя позволяет каждому соковыжималку иметь единый метод взаимодействия с ними без вызова (составного MasterJuicer), заботящегося о том, как они работают вместе. Это касается «поведенческого» аспекта.

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

Если вы не хотите регистрировать свои соковыжималки с помощью MasterJuicer вручную, вы можете захотеть получить умение с каким-либо открытием службы.Общей методикой в ​​Java является использование аннотаций и сканирование классов, чтобы найти классы во время выполнения и автоматически регистрировать их при запуске. Доступны a few libraries, которые делают это, или если вы уже используете Spring Framework, вы можете использовать его built-in scanning tools.

Answer 2

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

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

Answer 3

Я предлагаю вам Decorator Pattern

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

Надеюсь, это поможет!

Answer 4

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

http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

рассматривает

Answer 5

Это, безусловно, цепь ответственности. Каким-то образом перебирайте Juicers и создавайте сок до тех пор, пока вы не сойдете с фруктов. Некоторые вещи, которые следует учитывать, - это необходимость смешать полученные соки (возможно, сложный узор на Juice) и как организовать приоритет (если две соковыжималки сок грейпфрута, который должен это сделать?). Инкапсулируйте всю эту логику за интерфейс Juicer.