Разница между моделью стратегии и моделью делегирования

Question

В чем разница между шаблоном стратегии и шаблоном делегирования (не делегатами)?

Answer 1

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

• интерфейс под названием Стратегия (или со Стратегией как частью названия). этот интерфейс должен иметь метод execute ().
• один или несколько конкретных классов, называемых чем-то вроде ConcreteStrategyA, ConcreteStrategyB и т. Д., Которые реализуют интерфейс стратегии.
• также должен быть контекстный класс, содержащий стратегию

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

Сказав все это, не беспокойтесь о шаблонах. Сосредоточьтесь на принципах, и если вы чувствуете, что ваше решение может быть улучшено - посмотрите на шаблоны, чтобы увидеть, есть ли лучшая мышеловка. Если вы сосредоточитесь на шаблонах, а не на принципалах, вы потеряетесь во всех шаблонах и шаблонах реализации ради реализации шаблонов ...

Answer 2

«Делегирование» на самом деле не шаблон проектирования, это скорее общая методика программирования, где компонент A делегирует задачу (независимо от того, какая это может быть задача) компоненту B. Делегирование может использоваться во многих контекстах.

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

Например, вы можете реализовать шаблон стратегии и вызывать его, используя

strategy.execute(x)

Шаблон стратегии включает в себя наличие различных реализаций интерфейса вашей Стратегии и выбор соответствующей реализации во время выполнения. Актом вызова этой реализации является делегирование.

Так что это не так, или / или, концепции являются дополнительными.

Answer 3

Вот мысль:

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

Если бы, с другой стороны, у меня была одна часть класса, которую я хочу иметь возможность обмениваться во время выполнения, я бы создал классы Стратегии с одним интерфейсом метода (например, executeCalculation) и сделал бы его агрегатным компонентом содержащий класс.

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

Answer 4

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

Я обнаружил, что эта страница ищет кого-то, кто мог бы высказать свое мнение о преимуществах использования маршрута шаблона проектирования, учитывая, что java 8 и C # теперь поддерживают передачу функций в качестве аргументов