Каковы различия между шаблоном разработки Стратегии и шаблоном разработки State? Я просматривал довольно много статей в Интернете, но не мог ясно различить разницу.

Может кто-нибудь объяснить, пожалуйста, разницу в терминах непрофессионала?

Честно говоря, эти две модели на практике довольно похожи, и определяющая разница между ними имеет тенденцию варьироваться в зависимости от того, кого вы спрашиваете. Некоторые популярные варианты:

• Состояния хранят ссылку на объект контекста, который их содержит. Стратегии нет.
• Состояниям разрешено заменять себя (т.е. изменять состояние объекта контекста на что-то другое), а стратегии - нет.
• Стратегии передаются объекту контекста в качестве параметров, а состояния создаются самим объектом контекста.
• Стратегии обрабатывают только одну конкретную задачу, в то время как государства обеспечивают базовую реализацию для всего (или почти всего) объекта контекста.

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

• Паттерн « Стратегия» на самом деле подразумевает другую реализацию, которая выполняет (в основном) одно и то же, так что одна реализация может заменить другую, как того требует стратегия. Например, у вас могут быть разные алгоритмы сортировки в шаблоне стратегии. Вызывающие объекты не меняются в зависимости от используемой стратегии, но независимо от стратегии цель одна и та же (сортировка коллекции).
• Государственная картина о делать разные вещи в зависимости от состояния, оставляя при этом вызывающий абонент освобожден от бремени размещения каждых из возможных состояний. Так, например, у вас может быть getStatus()метод, который будет возвращать различные состояния в зависимости от состояния объекта, но вызывающий метод не должен кодироваться по-разному для учета каждого потенциального состояния.

Разница заключается лишь в том, что они решают разные проблемы:

• В государственной модели имеет дело с того, что (состоянием или типа) объект находится (в) - он инкапсулирует зависящее от состояния поведения, в то время как
• в стратегии модель рассматривается как объект выполняет определенную задачу - он инкапсулирует алгоритм.

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

Несколько замечаний об их преимуществах:

Используя шаблон State, класс хранения состояний (контекст) освобождается от знания того, что это за состояние или тип и какие состояния или типы доступны. Это означает, что класс придерживается принципа открытого-закрытого проектирования (OCP): класс закрыт для изменений в том, что есть состояния / типы, но состояния / типы открыты для расширений.

При использовании паттерна « Стратегия» класс, использующий алгоритм (контекст), освобождается от знаний о том, как выполнить определенную задачу (- «алгоритм»). Этот случай также создает приверженность OCP; класс закрыт для изменений относительно того, как выполнить эту задачу, но дизайн очень открыт для добавления других алгоритмов для решения этой задачи.
Это, вероятно, также улучшает приверженность класса контекста принципу единой ответственности (SRP). В дальнейшем алгоритм становится легко доступным для повторного использования другими классами.

Может кто-нибудь объяснить, пожалуйста, с точки зрения непрофессионала?

Шаблоны проектирования на самом деле не являются концепцией «непрофессионала», но я постараюсь сделать это как можно более понятным. Любой шаблон дизайна можно рассматривать в трех измерениях:

1. Проблема, которую решает шаблон;
2. Статическая структура паттерна (диаграмма классов);
3. Динамика выкройки (диаграммы последовательности).

Давайте сравним состояние и стратегию.

Проблема, которую решает шаблон

State используется в одном из двух случаев [GoF book p. 306] :

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

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

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

Лично я не нашел эту модель такой полезной. Вы всегда можете реализовать конечные автоматы, используя таблицу поиска (это не OO-способ, но он работает довольно хорошо).

Стратегия используется для следующего [GoF book p. 316] :

• многие связанные классы отличаются только своим поведением. Стратегии предоставляют способ настроить класс с одним из многих поведений.
• вам нужны разные варианты алгоритма. Например, вы можете определить алгоритмы, отражающие различные компромиссы пространства / времени. Стратегии могут использоваться, когда эти варианты реализованы в виде иерархии классов алгоритмов [HO87].
• алгоритм использует данные, о которых клиенты не должны знать. Используйте шаблон «Стратегия», чтобы избежать выявления сложных, специфичных для алгоритма структур данных.
• класс определяет много поведений, и они появляются как несколько условных операторов в своих операциях. Вместо многих условных выражений перенесите соответствующие условные ветви в свой собственный класс Strategy.

Последний случай применения стратегии связан с рефакторингом, известным как « Заменить условный полиморфизмом». .

Резюме: государство и стратегия решают самые разные проблемы. Если ваша проблема не может быть смоделирована с помощью конечного автомата, то, скорее всего, шаблон State не подходит. Если ваша проблема не в инкапсуляции вариантов сложного алгоритма, тогда Стратегия не применяется.

Статическая структура рисунка

State имеет следующую структуру классов UML:

Стратегия имеет следующую структуру классов UML:

Резюме: с точки зрения статической структуры, эти две модели в основном идентичны. Фактически, инструменты обнаружения шаблонов, такие как этот, считают, что « структура шаблонов [...] идентична, что запрещает их различение автоматическим процессом (например, без ссылки на концептуальную информацию). ».

Однако может быть существенное различие, если ConcreteStates сами решают переходы состояний (см. « Может определить » ассоциации на диаграмме выше). Это приводит к связи между конкретными состояниями. Например (см. Следующий раздел), состояние A определяет переход в состояние B. Если класс Context принимает решение о переходе в следующее конкретное состояние, эти зависимости исчезают.

Динамика картины

Как упомянуто в разделе «Проблема» выше, « Состояние» подразумевает, что поведение изменяется во время выполнения в зависимости от некоторого состояния объекта. Следовательно, понятие перехода состояний применимо, как обсуждалось с отношением конечного автомата . [GoF] упоминает, что переходы могут быть определены либо в подклассах ConcreteState, либо в централизованном расположении (например, в расположении на основе таблицы).

Давайте предположим простой конечный автомат:

Предполагая, что подклассы решают переход состояния (возвращая следующий объект состояния), динамика выглядит примерно так:

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

Описание : Каждый шаблон использует полиморфный вызов, чтобы сделать что-то в зависимости от контекста. В паттерне State полиморфный вызов (переход) часто вызывает изменение следующего состояния . В шаблоне «Стратегия» полиморфный вызов обычно не меняет контекст (например, оплата кредитной картой один раз не означает, что вы будете платить через PayPal в следующий раз). Опять же, динамика паттерна состояний определяется соответствующим конечным автоматом, что (для меня) необходимо для правильного применения этого паттерна.

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

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

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

Рассмотрим систему IVR (Interactive Voice Response), которая обрабатывает звонки клиентов. Вы можете запрограммировать его на работу с клиентами по:

• Рабочие дни
• каникулы

Чтобы справиться с этой ситуацией, вы можете использовать State State .

• Отпуск : IVR просто отвечает, что « Звонить можно только в рабочие дни с 9 до 17 часов ».
• Рабочие дни : он отвечает, связывая клиента с руководителем службы поддержки клиентов.

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

• По-круговой
• Наименее недавно использованный
• Другие приоритетные алгоритмы

Шаблон стратегии определяет, « как » выполнить какое-либо действие, а шаблон состояния - « когда » их выполнять.

Стратегия представляет объекты, которые «делают» что-то, с одинаковыми начальными и конечными результатами, но внутренне с использованием разных методологий. В этом смысле они аналогичны представлению реализации глагола. Шаблон состояния OTOH использует объекты, которые «являются» чем-то - состоянием операции. Хотя они могут также представлять операции с этими данными, они больше похожи на представление существительного, чем на глагол, и ориентированы на конечные автоматы.

Стратегия: стратегия является фиксированной и обычно состоит из нескольких шагов. (Сортировка представляет собой только один шаг и, таким образом, является очень плохим примером, поскольку она слишком примитивна для понимания цели этого шаблона). Ваша «основная» рутина в стратегии вызывает несколько абстрактных методов. Например, «Войти в стратегию комнаты», «main-method» - это goThroughDoor (), который выглядит следующим образом: подхода Door (), if (locked ()) openLock (); открытая дверь(); enterRoom (); перемена(); закрой дверь(); if (wasLocked ()) lockDoor ();

Теперь подклассы этого общего «алгоритма» для перемещения из одной комнаты в другую через возможную запертую дверь могут реализовывать шаги алгоритма.

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

ЭТО ВЫШЕ - это Шаблонный Шаблон. Теперь поместите относящиеся друг к другу шаги (разблокировка / блокировка и открытие / закрытие) в свои собственные объекты реализации и делегируйте им. Например, замок с ключом и замок с кодовой картой - это два вида замков. Делегирование от стратегии до объектов «Шаг». Теперь у вас есть шаблон стратегии.

Государственный паттерн - это нечто совершенно другое.

У вас есть оберточный объект и обернутый объект. Завернутый - это «состояние». Доступ к объекту состояния возможен только через его оболочку. Теперь вы можете изменить обернутый объект в любое время, поэтому оболочка, похоже, меняет свое состояние или даже «класс» или тип.

Например, у вас есть сервис входа в систему. Он принимает имя пользователя и пароль. У него есть только один метод: вход в систему (String userName, String passwdHash). Вместо того, чтобы решать для себя, принят ли вход в систему или нет, он делегирует решение объекту состояния. Этот объект состояния обычно просто проверяет, является ли комбинация пользователь / пароль действительной, и выполняет вход в систему. Но теперь вы можете обменять «Checker» на тот, который позволяет входить только привилегированным пользователям (например, во время обслуживания), или на тот, который не позволяет никому входить в систему. Это означает, что «средство проверки» выражает «состояние входа в систему» ​​системы.

Самое важное отличие: когда вы выбираете стратегию, вы придерживаетесь ее, пока не закончите с ней. Это означает, что вы называете его «основным методом», и пока он работает, вы никогда не меняете стратегию. OTOH в ситуации паттерна состояния во время работы вашей системы вы меняете состояние произвольно по своему усмотрению.

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

Диаграмма UML из статьи вики- стратегии:

Ключевая особенность:

1. Это поведенческий паттерн.
2. Это основано на делегировании.
3. Он изменяет внутренности объекта, изменяя поведение метода.
4. Он используется для переключения между семейством алгоритмов.
5. Это изменяет поведение объекта во время выполнения.

Обратитесь к этому сообщению за дополнительной информацией и примерами из реальной жизни:

Пример шаблона стратегии в реальном мире

Государственный шаблон позволяет объектчтобы изменить свое поведениекогда его внутреннее состояние изменяется

UML-диаграмма из статьи-шаблона wiki State:

Если нам нужно изменить поведение объекта в зависимости от его состояния, мы можем иметь переменную состояния в объекте и использовать блок условия if-else для выполнения различных действий в зависимости от состояния. Государственный шаблон используется для обеспечения систематического и проигрывает Моноблочный пути для достижения этой цели через контекст и государственные реализации.

Обратитесь к этой journaldev статье для получения более подробной информации.

Основные отличия от статей об источниках и журналах :

1. Разница между государством и стратегией заключается во времени связывания. Стратегия представляет собой модель, обязывающую один раз, в то время как государство более динамично .
2. Разница между государством и стратегией заключается в намерении. Со Стратегией выбор алгоритма довольно стабилен . При использовании State изменение состояния объекта «context» заставляет его выбирать из своей «палитры» объектов Strategy .
3. Контекст содержит состояние в качестве переменной экземпляра, и может быть несколько задач, реализация которых может зависеть от состояния, тогда как в стратегии шаблон стратегии передается как аргумент методу, а объект контекста не имеет никакой переменной для его хранения.

На непрофессиональном языке,

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

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

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

Оба шаблона делегируют базовому классу, который имеет несколько производных, но только в шаблоне State эти производные классы содержат ссылку на класс контекста.

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

Для получения дополнительной информации: Роберт С. Мартин (и Мика Мартин) ответят на это в своей книге «Гибкие принципы, шаблоны и практики в C #». ( http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258 )

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

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

https://www.youtube.com/watch?v=e45RMc76884 https://www.tutorialspoint.com/design_pattern/state_pattern.htm

В случае паттерна «Стратегия» расположение диаграммы классов совпадает с паттерном состояния. Клиент приходит к этой договоренности, чтобы сделать некоторую операцию. То есть вместо разных состояний существуют разные алгоритмы, например, разные анализы, которые необходимо выполнить для шаблона. Здесь клиенты сообщают контексту, что он хочет сделать, какой алгоритм (определенный пользователем бизнес-алгоритм), а затем выполняет это.

https://www.tutorialspoint.com/design_pattern/strategy_pattern.htm

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

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

Состояние приходит с небольшими зависимостями внутри классов, производных от состояния: как одно состояние знает о других состояниях, следующих за ним. Например, лето наступает после зимы для любого состояния сезона или состояния доставки после состояния депозита для покупок.

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

Разница обсуждается в http://c2.com/cgi/wiki?StrategyPattern . Я использовал шаблон «Стратегия», позволяющий выбирать разные алгоритмы в общей структуре для анализа данных. Благодаря этому вы можете добавлять алгоритмы без необходимости изменять общие рамки и их логику.

Типичным примером является то, что у вас есть структура для оптимизации функции. Каркас устанавливает данные и параметры. Паттерн стратегии позволяет вам выбирать алгоритмы, такие как спуски с помощью шагов, сопряженные градиенты, BFGS и т. Д. Без изменения структуры.

Как Стратегия, так и структура государства имеют одинаковую структуру. Если вы посмотрите на диаграмму классов UML для обоих шаблонов, они выглядят одинаково, но их намерения совершенно разные. Шаблон проектирования состояния используется для определения и управления состоянием объекта, а шаблон стратегии - для определения набора взаимозаменяемых алгоритмов и позволяет клиенту выбрать один из них. Таким образом, паттерн «Стратегия» является паттерном, управляемым клиентом, в то время как «Объект» может управлять этим состоянием.

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

Когда у вас есть проект, который можно разделить на 2 задачи:

задача 1: вы можете использовать один из двух различных алгоритмов для выполнения: alg1, alg2

Задача 2: вы можете использовать один из трех различных алгоритмов для выполнения: alg3, alg4, alg5

alg1 и alg2 являются взаимозаменяемыми; alg3, alg4 и alg5 являются взаимозаменяемыми.

Выбор алгоритма для выполнения задачи 1 и 2 зависит от состояний:

состояние 1: вам нужно alg1 в задании 1 и alg3 в задании 2

состояние 2: вам нужно alg2 в задании 1 и alg5 в задании 2

Ваш контекст может изменить объект состояния из состояния 1 в состояние 2. Тогда ваша задача будет выполнена с помощью alg2 и alg5 вместо alg1 и alg3.

Вы можете добавить больше взаимозаменяемых алгоритмов для задачи 1 или задачи 2. Это шаблон стратегии.

Вы можете иметь больше состояний с различной комбинацией алгоритмов в задаче 1 и задаче 2. Шаблон состояний позволяет переключаться из одного состояния в другое и выполнять разные комбинации алгоритмов.

«Стратегия» - это всего лишь алгоритм, который вы можете изменить в различных обстоятельствах по своему усмотрению, и он что-то обрабатывает для вас. Ex. Вы можете выбрать, как сжать файл. zip или rar ... в методе.

Но «Состояние» МОЖЕТ изменить все поведение вашего объекта, когда оно меняется, даже если оно может изменить другие поля ... вот почему у него есть ссылка на его владельца. Вы должны заметить, что изменение поля объекта может вообще изменить поведение объекта. Ex. когда вы меняете State0 на State1 в obj, вы меняете целое число на 10 .. поэтому, когда мы вызываем obj.f0 (), который выполняет некоторые вычисления и использует это целое число, это влияет на результат.