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

1) Strategy $Стратегия$

Суть: инкапсулировать семейство алгоритмов и менять их во время выполнения. Контекст делегирует вызов выбранной стратегии.Когда применять:
Нужны альтернативные реализации одного и того же поведения $алгоритма$, которые нужно подменять в рантайме или выбирать конфигурацией.Алгоритмы независимы друг от друга и не должны знать о состоянии контекста.Нужно упростить тестирование/расширение $добавлениеновойстратегиибезизмененияклиента$.Примеры:
Разные методы сериализации: JSON, XML, Proto — выбираются в зависимости от конфигурации.Алгоритмы сортировки/фильтрации/кэширования $LRU,LFUит.п.$.Платежные шлюзы: Stripe, PayPal, банковский эквайринг — общий интерфейс charge.Доводы в пользу:
SRP / Open-Closed: новые алгоритмы добавляются без изменения клиентского кода.Тестируемость $каждуюстратегиюможнопротестироватьотдельно$.Когда усложняет код:
Если альтернатив всего две и они простые — проще if/else или switch.Если стратегия — одноразовая маленькая функция, то лямбда/функциональный параметр проще.Большое количество мелких классов только ради одной-двух функций — избыточно.

2) State $Состояние$

Суть: инкапсулировать поведение объекта, зависящее от его внутреннего состояния; объект меняет состояние и поведение динамически, состояния часто сами управляют переходами.Когда применять:
Поведение объекта существенно меняется при смене состояния.Есть явно выраженные состояния и набор допустимых переходов между ними.Логика переходов и реакции на события лучше инкапсулировать вместе с состоянием $избегаябольшогочислаif/elseпоenum$.Примеры:
Сетевые соединения: состояния CLOSED, LISTEN, ESTABLISHED с различной реакцией на входящие пакеты/события.Документ в системе публикации: Draft → Moderation → Published, где методы edit, publish, rollback ведут себя по‑разному.Автомат с этапами: ожидание монеты, выбор продукта, выдача товара.Доводы в пользу:
Убирает разрастание условных операторов, делает переходы явными.Легче добавить новое состояние с собственной логикой.Когда усложняет код:
Если «состояний» немного и переходы тривиальны — enum + switch проще.Если поведение зависит не от внутренней модели, а от внешних условий, лучше использовать Strategy или фабрики.Когда состояния дублируют логику, а переходы предсказуемы — паттерн добавляет лишние классы.

3) Chain of Responsibility $Цепочкаобязанностей$

Суть: набор обработчиков, которые последовательно принимают запрос; каждый обработчик либо обрабатывает запрос, либо передаёт дальше.Когда применять:
Необходимо разделить конвейер обработки запроса на независимые шаги, порядок может быть конфигурируемым.Нельзя заранее знать, какой обработчик справится с запросом.Нужны гибкие цепочки middleware/фильтров $веб‑middleware,события$.Примеры:
HTTP middleware: аутентификация → валидация → логирование → роутинг.Обработка команд/запросов: несколько провайдеров могут выполнить команду, первый подходящий — обрабатывает.Валидация формы: последовательность проверок, остановка при первой ошибке или накопление ошибок.Доводы в пользу:
Разделение ответственности, легко вставлять/удалять шага.Подходит для pipeline-архитектуры, где обработка должна проходить через набор независимых фильтров.Когда усложняет код:
Если все обработчики обязаны выполняться $ненуженкороткий-circuit$, лучше использовать явную последовательность функций/коллекцию вызовов.Если порядок обработки критичен и жёстко фиксирован — цепочка усложняет понимание.Отладка сложнее: трассировка прохождения через цепочку, нежелательная последовательность вызовов.Когда логика отказа/откатов/транзакций нужна — простая CoR может не подойти.

Сравнение и ориентиры при выборе

Strategy vs State:
Strategy — выбор алгоритма, обычно контекст не меняет стратегию сам по себе; стратегии не участвуют в изменении состояния контекста.State — поведение зависит от внутреннего состояния объекта; состояния могут сами менять состояние $переходы$.Если у вас набор алгоритмов, подставляемых извне → Strategy. Если поведение меняется в ответ на события и нужно моделировать переходы → State.Strategy vs Chain of Responsibility:
Strategy: один выбранный алгоритм исполняется.CoR: последовательность обработчиков, первый подходящий или все по очереди.Если нужно выбрать один обработчик — можно и CoR, но Strategy/Factory проще и предсказуемее.State vs CoR:
State — поведение единственного объекта меняется в зависимости от его состояния.CoR — несколько независимых обработчиков на пути запроса; цепочка обычно глобальная/внешняя по отношению к запросу.

Практическое руководство $чеклист$

Нужны независимые алгоритмы, которые клиент выбирает/конфигурирует → Strategy.Объект «живет» в состоянии и поведение/допустимые операции меняются динамически, нужно моделировать переходы → State.Нужен конвейер обработки запросов/фильтров, порядок/набор обработчиков изменяем → Chain of Responsibility $илиmiddleware$.Если реализация проста и вариантов мало — сначала используйте простые if/else, функции или enum+switch; рефакторьте в паттерн, когда усложнение растёт.

Краткие примеры «перегиба»

Strategy: для выбора между print/printf и println делать 5 классов — избыточно.State: для объекта с двумя флагами и парой простых проверок — лучше условный оператор.CoR: для линейной последовательности фиксированных шагов, которые всегда выполняются — лучше обычная императивная последовательность или pipeline без авто‑прерывания.

Если нужно — могу привести маленькие примеры кода $псевдо/наJava,Pythonилидругомязыке$ для каждого паттерна и примеры их упрощённых замен.