Я недавно начал изучать шаблоны проектирования, и одна вещь, которую я кодирую, идеально подошла бы к шаблону стратегии, за исключением одного небольшого различия.
По сути, некоторые (но не все) из моих алгоритмов нуждаются в дополнительном параметре или двух передаваемых им.
Так что мне либо нужно
- передать им дополнительный параметр, когда я вызываю их метод вычисления
или же
- сохраните их как переменные внутри класса ConcreteAlgorithm и сможете обновить их, прежде чем я вызову алгоритм.
Существует ли шаблон проектирования для этой потребности / Как я могу реализовать это, придерживаясь шаблона стратегии?
Я рассмотрел передачу объекта client во все алгоритмы и сохранение там переменных, а затем использовал его только тогда, когда это требуется конкретному алгоритму. Тем не менее, я думаю, что это и громоздко, и побеждает смысл стратегии.
Просто чтобы прояснить, я реализую в Java, и поэтому не могу позволить себе роскошь дополнительных параметров (что решило бы это хорошо).
источник
Ответы:
Сэмюэль, возможно ли инкапсулировать параметр, который каждая из стратегий принимает в один общий класс, и затем расширить этот общий класс Parameter, чтобы добавить больше поведения, которое особенно необходимо для некоторых из ваших стратегий?
Например
Затем определите иерархию стратегии, например:
назвать вышеуказанную стратегию как:
myNormalStrategyInstance.myStrategyMethod(strategyParameter);
вызвать вышеупомянутую стратегию, передавая
SpecialStrategyParameter
экземпляр вместо:mySpecializedStrategy.myStrategyMethod(specialStrategyParameter);
Пожалуйста, обновите, если что-то не понятно. Будем рады объяснить / уточнить.
источник
StrategyParameter
содержать все возможные параметры, как DTO. Некоторые реализации стратегии могут их игнорировать. В некоторых случаях это лучший подход. Контекст является королем для такого рода вопросов.Вам необходимо уточнить вашу стратегию .
Все зависит от того, как вы используете свои алгоритмы. Чтобы ваш клиентский класс использовал различные реализации стратегии взаимозаменяемо, все они должны иметь общую абстракцию . Если они не следуют одному и тому же интерфейсу, возможно, вам нужны разные абстракции .
Ранее я использовал настраиваемые стратегии, в которых вы параметризовали конкретные классы построения:
Теперь кому-то еще нужно создать экземпляр этого класса и передать его вашему клиенту. Но вашему клиенту все еще нужно знать об
Strategy
интерфейсе.Это также работает, если ваш метод стратегии принимает параметры, но тогда ваш клиент знает об этих параметрах и передает их всем реализациям, с которыми он работает.
источник
Пока подпись определена на интерфейсе четко, она все еще соответствует шаблону Стратегии.
Шаблоны, как написано, являются самой простой формой, которая все еще демонстрирует ожидаемое поведение, поэтому вы можете приукрашивать их, сохраняя первоначальные намерения. Это, конечно, предполагает, что вы хотите следовать шаблону. Нет смысла использовать шаблон, если он не подходит или просто потому, что он есть, но в вашем случае я думаю, что вы в порядке.
источник
расширяя ответ выше, предоставленный peakit - вы можете использовать абстракцию. Я использую код Пикита здесь -
Интерфейс MyStrategy { abstract void myStrategyMethod (параметр StrategyParameter); }
класс MyNormalStrategy extends MyStrategy {публичное переопределение void myStrategyMethod (параметр StrategyParameter) {// реализовать логику здесь}}
класс MySpecializedStrategy extends MyStrategy {public override void myStrategyMethod (параметр StrategyParameter, ExtraStrategyParameter extraParameter) {// реализуем логику здесь} }
Если я правильно понимаю ваш вопрос, вы хотите передать дополнительный параметр некоторым алгоритмам, верно? Пожалуйста, дайте мне знать, если это то, что вы искали?
источник
Если вы загляните в книгу «Шаблоны проектирования», то, по сути, нет ничего плохого в том, что существует какая-то SimpleStrategy, которая использует меньше или ни один из переданных параметров, или что параметры представляют собой множитель «один размер подходит для всех / наименьшего общего числа». Выбор дизайна в данном случае заключается в том, наносит ли это вам вред с точки зрения дополнительной обработки, которая в итоге не используется.
источник