В чем разница между шаблоном проектирования стратегии и шаблоном государственного дизайна? Я просматривал довольно много статей в Интернете, но не мог четко различить.
Кто-нибудь может объяснить разницу в неспециалистских терминах?
В чем разница между шаблоном проектирования стратегии и шаблоном государственного дизайна? Я просматривал довольно много статей в Интернете, но не мог четко различить.
Кто-нибудь может объяснить разницу в неспециалистских терминах?
Честно говоря, эти два шаблона довольно похожи на практике, и определяющая разница между ними имеет тенденцию варьироваться в зависимости от того, кого вы спрашиваете. Некоторые популярные варианты:
"Классическая" реализация будет соответствовать либо состоянию, либо стратегии для каждого элемента в списке, но вы выполняете гибриды, в которых есть смеси обоих. Является ли конкретным больше State-y или Strategy-y, в конечном счете, является субъективным вопросом.
getStatus()
который будет возвращать различные состояния в зависимости от состояния объекта, но вызывающий метод не должен кодироваться по-разному для учета каждого потенциального состояния.Разница заключается лишь в том, что они решают разные проблемы:
Конструкции для достижения этих разных целей, однако, очень похожи; оба шаблона являются примерами композиции с делегацией.
Некоторые наблюдения за их преимуществами:
Используя шаблон состояния, класс состояния (контекста) освобождается от знания состояния того, что, или его типа, и того, какие состояния или типы доступны. Это означает, что класс придерживается принципа открытого закрытия (OCP): класс закрыт для изменений в том, какие состояния/типы существуют, но состояния/типы открыты для расширений.
Используя шаблон стратегии, класс использования алгоритма (контекста) освобождается от знания , как выполнять определенную задачу (- "алгоритм" ). Этот случай также создает приверженность OCP; класс закрыт для изменений в отношении того, как выполнить эту задачу, но дизайн очень открыт для добавления других алгоритмов для решения этой задачи.
Это, вероятно, также улучшает соответствие класса контекста принципу единой ответственности (СРП). Далее алгоритм становится легко доступным для повторного использования другими классами.
Может кто-нибудь объяснить, пожалуйста, с точки зрения непрофессионала?
Шаблоны проектирования на самом деле не являются концепцией "непрофессионала", но я постараюсь сделать это как можно яснее Любой шаблон дизайна можно рассматривать в трех измерениях:
Давай сравним состояние и стратегию.
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 в следующий раз). Опять же, динамика паттерна состояний определяется соответствующим конечным автоматом, что (для меня) необходимо для правильного применения этого паттерна.
Шаблон стратегии включает в себя перемещение реализации алгоритма из класса хостинга и помещение его в отдельный класс. Это означает, что хост-класс не должен обеспечивать реализацию каждого алгоритма, что может привести к нечистому коду.
Алгоритмы сортировки обычно используются в качестве примера, поскольку все они делают одно и то же (сортировка). Если каждый отдельный алгоритм сортировки помещается в свой собственный класс, то клиент может легко выбрать, какой алгоритм использовать, и шаблон предоставляет простой способ доступа к нему.
Шаблон состояния включает изменение поведения объекта при изменении состояния объекта. Это означает, что класс-хост не обеспечивает реализацию поведения для всех разных состояний, в которых он может находиться. Класс-хост обычно инкапсулирует класс, который предоставляет функциональные возможности, необходимые в заданном состоянии, и переключается на другой класс когда состояние изменяется.
Стратегия представляет объекты, которые "что-то делают", с теми же начальными и конечными результатами, но внутренне используют разные методологии. В этом смысле они аналогичны представлению о реализации глагола. В шаблоне состояния OTOH используются объекты, которые "являются" чем-то - состоянием операции. Хотя они также могут представлять операции над этими данными, они более похожи на представление существительного, чем глагола, и адаптируются к государственным машинам.
Рассмотрим систему IVR (Interactive Voice Response), обрабатывающую вызовы клиентов. Вы можете запрограммировать его для обработки клиентов:
Чтобы справиться с этой ситуацией, вы можете использовать шаблон State.
Этот процесс подключения клиента к руководителю службы поддержки может быть реализован с использованием Стратегического паттерна, где руководители выбираются на основе любого из:
Шаблон стратегии решает " как" выполнять некоторые действия, а шаблон состояния решает ", когда" выполнять их.
Стратегия: стратегия фиксирована и обычно состоит из нескольких этапов. (Сортировка представляет собой только один шаг и, следовательно, очень плохой пример, поскольку он слишком примитивен, чтобы понять цель этого шаблона). Ваша "основная" рутина в стратегии вызывает несколько абстрактных методов. Например. "Enter Room Strategy", "main-method" - goThroughDoor(), который выглядит так: approachDoor(), if (locked()) openLock(); открытая дверь(); enterRoom(); очередь(); закрой дверь(); if (wasLocked()) lockDoor();
Теперь подклассы этого общего "алгоритма" для перемещения из одной комнаты в другую комнату через возможную заблокированную дверь могут реализовать этапы алгоритма.
Другими словами, подклассификация стратегии не изменяет основные алгоритмы, а только отдельные шаги.
ЭТО ВЫШЕ - шаблон шаблона. Теперь поместите шаги, принадлежащие вместе (разблокировка/блокировка и открытие/закрытие) в свои собственные объекты реализации и делегируйте их. Например. замок с ключом и замок с кодовой карточкой - это два вида замков. Делегат от стратегии до объектов "Шаг". Теперь у вас есть шаблон стратегии.
Шаблон состояния - это нечто совершенно другое.
У вас есть оберточный объект и обернутый объект. Обернутый - это "состояние". Объект состояния доступен только через его обертку. Теперь вы можете изменить обернутый объект в любое время, поэтому оболочка, похоже, изменит свое состояние или даже его "класс" или тип.
например. у вас есть вход в систему. Он принимает имя пользователя и пароль. Он имеет только один метод: logon (String userName, String passwdHash). Вместо того, чтобы решать, принимается ли вход в систему или нет, он делегирует решение государственному объекту. Этот объект состояния обычно просто проверяет правильность комбинации пользователя и пароля и выполняет вход в систему. Но теперь вы можете обменивать "Checker" на тот, который разрешает только привилегированным пользователям (в течение времени maintanace, например,) или одному, который не позволяет никому войти в систему. Это означает, что "checker" выражает "статус регистрации" в системе.
Самое важное различие: когда вы выбрали стратегию, которую вы придерживаетесь, пока вы не закончите с ней. Это означает, что вы называете его "основным методом", и пока он работает, вы никогда не изменяете стратегию. OTOH в ситуации штатного шаблона во время работы вашей системы вы меняете состояние произвольно, как вы сочтете нужным.
Шаблон стратегии используется, когда у вас есть несколько алгоритмов для конкретной задачи, и клиент решает, какую фактическую реализацию использовать во время выполнения.
Диаграмма UML из статьи вики- стратегии:
Ключевая особенность:
Обратитесь к этому сообщению для получения дополнительной информации и примеров из реальной жизни:
Пример шаблона стратегии в реальном мире
Паттерн состояние позволяет объект, чтобы изменить свое поведение, когда его внутреннее состояние изменяется
UML-диаграмма из статьи-шаблона wiki State:
Если нам нужно изменить поведение объекта в зависимости от его состояния, мы можем иметь переменную состояния в объекте и использовать блок условия if-else для выполнения различных действий в зависимости от состояния. Паттерн состояния используется для обеспечения систематических и потерять связь способа достичь этого через контекст и государственные реализации.
Обратитесь к этой journaldev статье для получения более подробной информации.
Основные отличия от статей об источниках и журналах :
В языке неспециалиста
в шаблоне стратегии нет состояний, или все из них имеют одинаковое состояние. У всех есть разные способы выполнения задачи, так как разные врачи одинаково относятся к одному и тому же пациенту с одинаковым состоянием по-разному.
В шаблоне состояния субъективно есть состояния, такие как текущее состояние пациента (скажем, высокая температура или низкая температура), на основе которого будет определен следующий курс действий (рецепт лекарства). И одно состояние может привести к другому состоянию, поэтому существует государственная зависимость (композиция технически).
Если мы технически попытаемся понять это, основываясь на сравнении кода обоих, мы можем потерять субъективность ситуации, потому что оба выглядят очень похожими.
Оба шаблона делегируют базовому классу, который имеет несколько производных, но только в шаблоне State эти производные классы содержат ссылку на класс контекста.
Другой способ взглянуть на это состоит в том, что шаблон "Стратегия" является более простой версией шаблона "Состояние"; подшаблон, если хотите. Это действительно зависит от того, хотите ли вы, чтобы производные состояния содержали ссылки на контекст или нет (то есть: хотите ли вы, чтобы они вызывали методы в контексте).
Для получения дополнительной информации: Роберт С. Мартин (и Мика Мартин) ответят на это в своей книге "Гибкие принципы, модели и практики в С#". (http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258)
Это довольно старый вопрос, но все же я тоже искал те же ответы, и это то, что я обнаружил.
Для шаблона State рассмотрим пример кнопки Medial Player Play. Когда мы играем, он начинает играть и дает контексту понять, что он играет. Каждый раз, когда клиент хочет выполнить игру, он проверяет текущее состояние плеера. Теперь клиент знает, что состояние объекта играет через объект контекста, поэтому он вызывает метод действий объектов состояния паузы. Часть клиента, реализующего государство и в каком состоянии он должен выполнять действия, может быть автоматизирован.
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. Я использовал шаблон стратегии, позволяющий выбирать различные алгоритмы в общей структуре для анализа данных. Благодаря этому вы можете добавлять алгоритмы без необходимости изменения общих фреймворков и их логики.
Типичным примером является то, что у вас есть инфраструктура для оптимизации функции. Структура устанавливает данные и параметры. Шаблон стратегии позволяет вам выбирать алгоритмы, такие как sttepest descents, сопряженные градиенты, BFGS и т.д., Не изменяя рамки.
Оба шаблона Strategy and State имеют одинаковую структуру. Если вы посмотрите на диаграмму классов UML для обоих шаблонов, они выглядят точно так же, но их намерения совершенно разные. Шаблон государственного образца используется для определения и управления состоянием объекта, а шаблон стратегии используется для определения набора взаимозаменяемых алгоритмов и позволяет клиенту выбрать один из них. Таким образом, шаблон стратегии является шаблоном, управляемым клиентом, в то время как Object может управлять этим состоянием.
Короче говоря, с помощью паттерна стратегии мы можем установить некоторое поведение на лету, а с паттерном состояния мы можем быть уверены, что объект изменит свое поведение внутренне с изменением своего состояния.
Когда у вас есть проект, который можно разделить на 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. Шаблон состояний позволяет переключаться из одного состояния в другое и выполнять различную комбинацию алгоритмов.
Эта ссылка объясняет сходства и различия двух шаблонов просто: стратегия и шаблон государственного дизайна