전략 디자인 패턴과 상태 디자인 패턴의 차이점은 무엇입니까?

전략 디자인 패턴과 상태 디자인 패턴의 차이점은 무엇입니까?

---

전략 디자인 패턴과 상태 디자인 패턴의 차이점은 무엇입니까? 나는 웹에서 꽤 많은 기사를 겪었지만 분명하게 차이를 만들 수 없었습니다.

평신도의 차이점에 대해 설명해 주시겠습니까?

---

솔직히, 두 패턴은 실제로는 매우 유사하며, 그 차이를 정의하는 것은 요청한 사람에 따라 달라지는 경향이 있습니다. 인기있는 선택은 다음과 같습니다.

• 상태는이를 포함하는 컨텍스트 객체에 대한 참조를 저장합니다. 전략은 그렇지 않습니다.
• 전략은 그렇지 않지만 국가는 스스로를 대체 할 수있다 (IE : 문맥 객체의 상태를 다른 것으로 바꾸는 것).
• 전략은 컨텍스트 개체에 매개 변수로 전달되는 반면 상태는 컨텍스트 개체 자체에 의해 생성됩니다.
• 전략은 하나의 특정 작업 만 처리하는 반면 상태는 컨텍스트 개체가 수행하는 모든 작업 (또는 대부분의 모든 작업)에 대한 기본 구현을 제공합니다.

"클래식"구현은 목록의 모든 항목에 대해 State 또는 Strategy와 일치하지만 둘을 혼합 한 하이브리드에서 실행됩니다. 특정 국가가 더 많은 국가 나 전략에 속하는지 여부는 궁극적으로 주관적인 질문입니다.

---

• 전략 패턴은 전략의 요구에 따라 하나의 구현이 다른 사람을 대체 할 수 그래서, (기본적으로) 수행 다른 구현 같은 일을하는 것에 대한 정말. 예를 들어 전략 패턴에 다른 정렬 알고리즘이있을 수 있습니다. 개체에 대한 호출자는 사용되는 전략에 따라 변경되지 않지만 전략에 관계없이 목표는 동일합니다 (수집 정렬).
• 주 패턴은 모든 가능한 상태를 수용하는 부담에서 해방 발신자를 유지하면서, 상태에 따라 다른 일을 대한 것입니다. 예를 들어 getStatus()객체의 상태에 따라 다른 상태를 반환 하는 메서드가있을 수 있지만 메서드의 호출자는 각 잠재적 상태를 설명하기 위해 다르게 코딩 할 필요는 없습니다.

---

차이점은 단순히 다른 문제를 해결한다는 것입니다.

• 주 패턴 상품의 어떤 객체가 (에)입니다 (주 또는 타입) - 그것은 반면, 상태에 의존하는 동작을 캡슐화
• 전략 패턴 거래 방법 객체가 특정 작업을 수행하는이 -이 알고리즘을 캡슐화합니다.

그러나 서로 다른 목표를 달성하기위한 구성은 매우 유사합니다. 두 패턴 모두 위임이있는 구성의 예입니다.

---

그들의 장점에 대한 관찰 :

사용하여 주 패턴을 국가 지주 (컨텍스트) 클래스의 지식 안도 어떤 상태 또는이고 무엇이 상태 또는 사용할 수있는 유형을 입력합니다. 이는 클래스가 OCP (Open-Closed Design Principal)를 준수 함을 의미합니다. 클래스는 상태 / 유형의 변화에 ​​따라 닫히지 만 상태 / 유형은 확장 가능합니다.

전략 패턴 을 사용하면 알고리즘 사용 (컨텍스트) 클래스가 특정 작업 ( "알고리즘")을 수행하는 방법 에 대한 지식이 없어집니다 . 이 경우에도 OCP를 준수합니다. 이 작업을 수행하는 방법에 대한 변경 사항은 클래스가 닫히지 만 디자인은이 작업을 해결하기 위해 다른 알고리즘을 추가 할 수 있습니다.
이는 컨텍스트 클래스의 단일 책임 원칙 (SRP) 준수를 향상시킬 수도 있습니다. 또한 알고리즘은 다른 클래스에서 쉽게 재사용 할 수있게됩니다.

---

누군가 평신도의 용어로 설명해 주시겠습니까?

디자인 패턴은 실제로 "레이맨"개념은 아니지만 가능한 한 명확하게하기 위해 노력할 것입니다. 모든 디자인 패턴은 3 차원으로 고려 될 수 있습니다.

1. 패턴이 해결하는 문제;
2. 패턴의 정적 구조 (클래스 다이어그램)
3. 패턴의 역학 (시퀀스 다이어그램).

상태와 전략을 비교해 봅시다.

패턴이 해결하는 문제

상태 는 두 경우 중 하나에 사용됩니다 [GoF book p. 306] :

• 객체의 동작은 상태에 따라 다르며 해당 상태에 따라 런타임에 동작을 변경해야합니다.
• 작업에는 개체의 상태에 따라 큰 여러 부분으로 된 조건문이 있습니다. 이 상태는 일반적으로 하나 이상의 열거 된 상수로 표시됩니다. 종종 여러 작업에 동일한 조건부 구조가 포함됩니다. 상태 패턴은 조건부의 각 분기를 별도의 클래스에 넣습니다. 이를 통해 객체 상태를 다른 객체와 독립적으로 변할 수있는 자체 객체로 취급 할 수 있습니다.

상태 패턴으로 해결되는 문제가 실제로 있는지 확인하려면 유한 상태 기계를 사용하여 객체의 상태를 모델링 할 수 있어야 합니다 . 여기 에서 적용된 예제를 찾을 수 있습니다 .

각 상태 전이는 상태 인터페이스의 방법입니다. 이는 디자인의 경우이 패턴을 적용하기 전에 상태 전이에 대해 확실해야 함을 의미합니다. 그렇지 않으면 전환을 추가하거나 제거하는 경우 인터페이스와 해당 전환을 구현하는 모든 클래스를 변경해야합니다.

나는 개인적 으로이 패턴을 유용하게 찾지 못했습니다. 룩업 테이블을 사용하여 유한 상태 머신을 항상 구현할 수 있습니다 (OO 방식은 아니지만 꽤 잘 작동합니다).

전략 은 다음 [GoF book p. 316] :

• 많은 관련 클래스는 동작이 다릅니다. 전략은 여러 가지 동작 중 하나를 사용하여 클래스를 구성하는 방법을 제공합니다.
• 알고리즘의 다른 변형이 필요합니다. 예를 들어, 다른 시공간 상충 관계를 반영하는 알고리즘을 정의 할 수 있습니다. 이러한 변형이 알고리즘의 클래스 계층으로 구현 될 때 전략을 사용할 수 있습니다 [HO87].
• 알고리즘은 클라이언트가 알아야 할 데이터를 사용합니다. 전략 패턴을 사용하면 복잡한 알고리즘 별 데이터 구조가 노출되지 않습니다.
• 클래스는 많은 동작을 정의하며 동작에서 여러 조건문으로 나타납니다. 많은 조건부 대신 관련 조건부 분기를 자체 전략 클래스로 이동하십시오.

전략을 적용 할 마지막 경우는 조건부를 다형성 으로 바꾸기로 알려진 리팩토링과 관련이 있습니다.

요약 : 상태 및 전략은 매우 다른 문제를 해결합니다. 유한 상태 머신으로 문제를 모델링 할 수없는 경우 상태 패턴이 적절하지 않을 수 있습니다. 복잡한 알고리즘의 변형을 캡슐화하는 것이 문제가 아니라면 전략이 적용되지 않습니다.

패턴의 정적 구조

State 는 다음 UML 클래스 구조를 갖습니다.

전략 은 다음과 같은 UML 클래스 구조를 갖습니다.

요약 : 정적 구조와 관련하여이 두 패턴은 대부분 동일합니다. 사실, 다음과 같은 패턴을 검출 툴 이 하나는 그 "고려 에서 [...] 동일한 패턴이다 (개념적 정보를 참조하지 않고, 예), 자동 공정에 의해 그 차이를 금지. 구조 "를

그러나 ConcreteStates가 자체적으로 상태 전이를 결정하는 경우 큰 차이가있을 수 있습니다 ( 위의 다이어그램에서 "" 결정할 수있는 "연관 "참조 ). 이로 인해 콘크리트 상태가 서로 연결됩니다. 예를 들어 (다음 섹션 참조) 상태 A는 상태 B 로의 전환을 결정합니다. 컨텍스트 클래스가 다음 구체적 상태로의 전환을 결정하면 이러한 종속성이 사라집니다.

패턴의 역학

위의 문제 섹션에서 언급 한 바와 같이, 국가는 일부에 따라 실행 시간에 그 동작 변경을 의미 상태 객체의를. 그러므로, 유한 상태 머신 의 관계에서 논의 된 바와 같이, 상태 천이 의 개념이 적용된다 . [GoF]는 전환이 ConcreteState 서브 클래스 또는 중앙 위치 (예 : 테이블 기반 위치)에서 정의 될 수 있다고 언급합니다.

간단한 유한 상태 머신을 가정 해 봅시다 :

서브 클래스가 다음 상태 객체를 반환하여 상태 전이를 결정한다고 가정하면 동적은 다음과 같습니다.

전략 의 역학을 보여주기 위해 실제 예제 를 빌리는 것이 유용합니다 .

Summary: Each pattern uses a polymorphic call to do something depending on the context. In the State pattern, the polymorphic call (transition) often causes a change in the next state. In the Strategy pattern, the polymorphic call does not typically change the context (e.g., paying by credit card once doesn't imply you'll pay by PayPal the next time). Again, the State pattern's dynamics are determined by its corresponding fininte state machine, which (to me) is essential to correct application of this pattern.

---

The Strategy Pattern involves moving the implementation of an algorithm from a hosting class and putting it in a separate class. This means that host class does not need to provide the implementation of each algorithm itself, which is likely to lead to unclean code.

Sorting algorithms are usually used as an example as they all do the same kind of thing (sort). If each differing sorting algorithm is put into its own class, then the client can easily choose which algorithm to use and the pattern provides an easy way to access it.

The State Pattern involves changing the behaviour of an object when the state of the object changes. This means that the host class does not have provide the implementation of behaviour for all the different states that it can be in. The host class usually encapsulates a class which provides the functionality that is required in a given state, and switches to a different class when the state changes.

---

Strategy represents objects that "do" something, with the same begin and end results, but internally using different methodologies. In that sense they are analogous to representing the implementation of a verb. The State pattern OTOH uses objects that "are" something - the state of an operation. While they can represent operations on that data as well, they are more analogous to representation of a noun than of a verb, and are tailored towards state machines.

---

Consider an IVR (Interactive Voice Response) system handling customer calls. You may want to program it to handle customers on:

• Work days
• Holidays

To handle this situation you can use a State Pattern.

• Holiday: IVR simply responds saying that 'Calls can be taken only on working days between 9am to 5pm'.
• Work days: it responds by connecting the customer to a customer care executive.

---

This process of connecting a customer to a support executive can itself be implemented using a Strategy Pattern where the executives are picked based on either of:

• Round Robin
• Least Recently Used
• Other priority based algorithms

The strategy pattern decides on 'how' to perform some action and state pattern decides on 'when' to perform them.

---

Strategy: the strategy is fixed and usually consists of several steps. (Sorting constitutes only one step and thus is a very bad example as it is too primitive in order to understand the purpose of this pattern). Your "main" routine in the strategy is calling a few abstract methods. E.g. "Enter Room Strategy", "main-method" is goThroughDoor(), which looks like: approachDoor(), if (locked()) openLock(); openDoor(); enterRoom(); turn(); closeDoor(); if (wasLocked()) lockDoor();

Now subclasses of this general "algorithm" for moving from one room to another room through a possible locked door can implement the steps of the algorithm.

In other words subclassing the strategy does not change the basic algorithms, only individual steps.

THAT ABOVE is a Template Method Pattern. Now put steps belonging together (unlocking/locking and opening/closing) into their own implementing objects and delegate to them. E.g. a lock with a key and a lock with a code card are two kinds of locks. Delegate from the strategy to the "Step" objects. Now you have a Strategy pattern.

A State Pattern is something completely different.

You have a wrapping object and the wrapped object. The wrapped one is the "state". The state object is only accessed through its wrapper. Now you can change the wrapped object at any time, thus the wrapper seems to change its state, or even its "class" or type.

E.g. you have a log on service. It accepts a username and a password. It only has one method: logon(String userName, String passwdHash). Instead of deciding for itself whether a log on is accepted or not, it delegates the decision to a state object. That state object usually just checks if the user/pass combination is valid and performs a log on. But now you can exchange the "Checker" by one that only lets priviledged users log on (during maintanace time e.g.) or by one that lets no one log on. That means the "checker" expresses the "log on status" of the system.

The most important difference is: when you have choosen a strategy you stick with it until you are done with it. That means you call its "main method" and as long as that one is running you never change the strategy. OTOH in a state pattern situation during the runtime of your system you change state arbitrarily as you see fit.

---

Strategy pattern is used when you have multiple algorithm for a specific task and client decides the actual implementation to be used at runtime.

UML diagram from wiki Strategy pattern article:

Key features:

1. It's a behavioural pattern.
2. It's based on delegation.
3. It changes guts of the object by modifying method behaviour.
4. It's used to switch between family of algorithms.
5. It changes the behaviour of the object at run time.

Refer to this post for more info & real world examples:

Real World Example of the Strategy Pattern

State pattern allows an object to alter its behaviour when its internal state changes

UML diagram from wiki State pattern article:

If we have to change the behavior of an object based on its state, we can have a state variable in the Object and use if-else condition block to perform different actions based on the state. State pattern is used to provide a systematic and lose-coupled way to achieve this through Context and State implementations.

Refer to this journaldev article for more details.

Key differences from sourcemaking and journaldev articles:

1. The difference between State and Strategy lies with binding time. The Strategy is a bind-once pattern, whereas State is more dynamic.
2. The difference between State and Strategy is in the intent. With Strategy, the choice of algorithm is fairly stable. With State, a change in the state of the "context" object causes it to select from its "palette" of Strategy objects.
3. Context contains state as instance variable and there can be multiple tasks whose implementation can be dependent on the state whereas in strategy pattern strategy is passed as argument to the method and context object doesn’t have any variable to store it.

---

In layman's language,

in Strategy pattern, there are no states or all of them have same state. All one have is different ways of performing a task, like different doctors treat same disease of same patient with same state in different ways.

In state Pattern, subjectively there are states, like patient's current state(say high temperature or low temp), based on which next course of action(medicine prescription) will be decided.And one state can lead to other state, so there is state to state dependency( composition technically).

If we technically try to understand it , based on code comparison of both, we might lose the subjectivity of situation,because both look very similar.

---

Both patterns delegate to a base class that has several derivative, but it's only in the State pattern that these derivative classes hold a reference back to context class.

Another way to look at it is that the Strategy pattern is a simpler version of the State pattern; a sub-pattern, if you like. It really depends if you want the derived states to hold references back to the context or not (i.e: do you want them to call methods on the context).

For more info: Robert C Martin (& Micah Martin) answer this in their book, "Agile Principles, Patterns and Practices in C#". (http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258)

---

This is a pretty old question, but still, I was also looking for the same answers and this is what I have discovered.

For State pattern lets consider an example of Medial Player Play button. When we do play it starts playing and makes the context aware that it is playing. Every time the client wants to perform play operation he checks the current state of the player. Now the client knows the state of the object is playing via the context object so he calls the pause state objects actions method. The part of the client realizing the state and on what state it needs to do action can be automated.

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

In the case of Strategy pattern, the arrangement of the class diagram is same as state pattern. The client comes to this arrangement to do some operation. That is instead of the different states there are different algorithms say for example different analysis that needs to be performed on the pattern. Here the clients tell the context what it wants to do that what algorithm (business defined custom algorithm) and then performs that.

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

Both implements open close principle so the developer has the capability to add new states to the state pattern and new algorithm.

But the difference is what they are used that is state pattern used to execute different logic based on a state of the object. And in a case of strategy different logic.

---

State comes with a little bit dependencies within the state derived classes: like one state knows about other states coming after it. For example, Summer comes after winter for any season state, or Delivery state after the Deposit state for shopping.

On the other hand, Strategy has no dependencies like these. Here, any kind of state can be initialized based on the program/product type.

---

The difference is discussed in http://c2.com/cgi/wiki?StrategyPattern. I have used the Strategy pattern for allowing different algorithms to be chosen within an overall framework for analysing data. Through that you can add algorithms without having to change the overall frameworks and its logic.

A typical example is that you amy have a framework for optimising a function. The framework sets up the data and parameters. The strategy pattern allows you to select algorithms such as sttepest descents, conjugate gradients, BFGS, etc. without altering the framework.

---

Both Strategy and State pattern has the same structure. If you look at the UML class diagram for both patterns they look exactly same, but their intent is totally different. State design pattern is used to define and manage state of an object, while Strategy pattern is used to define a set of interchangeable algorithm and lets client to choose one of them. So Strategy pattern is a client driven pattern while Object can manage there state itself.

---

In short, with the strategy pattern we can set some behavior on the fly, with state pattern, we can be sure, that an object will change its behavior internally with the change of its state.

---

When you have a project which can be divided into 2 tasks:

task 1: you can use one of two different algorithms to accomplish: alg1, alg2

task 2: you can use one of three different algorithms to accomplish: alg3, alg4, alg5

alg1 and alg2 are interchangeable; alg3, alg4 and alg5 are interchangeable.

Choosing which algorithm to perform in task 1 and task 2 depends on states:

state 1: you need alg1 in task 1 and alg3 in task 2

state 2: you need alg2 in task 1 and alg5 in task 2

You context can change state object from state 1 to state 2. Then your task would be accomplished by alg2 and alg5, instead of alg1 and alg3.

You can add more interchangeable algorithms for task 1 or task 2. This is strategy pattern.

You can have more states with different combination of algorithms in task 1 and task 2. State pattern allows you to switch from one state to another and perform different combination of algorithms.

---

'Strategy' is only an algorithm that you can change it in different circumstances upon your need, and it processes something for you. Ex. you can choose how compress a file. zip or rar ... in a method.

그러나 '상태'는 모든 객체의 동작이 변경 될 때 변경 될 수 있습니다. 심지어 다른 필드도 변경할 수 있습니다. 그래서 그 소유자에 대한 참조가 있습니다. 객체 필드를 변경하면 객체 동작이 전혀 변경 될 수 있습니다. 전의. obj에서 State0을 State1로 변경하면 정수를 10으로 변경합니다. 따라서 계산을 수행하고 해당 정수를 사용하는 obj.f0 ()을 호출하면 결과에 영향을줍니다.

참고 URL : https://stackoverflow.com/questions/1658192/what-is-the-difference-between-strategy-design-pattern-and-state-design-pattern