전략 디자인 패턴과 상태 디자인 패턴의 차이점은 무엇입니까? 나는 웹에서 꽤 많은 기사를 겪었지만 차이점을 명확하게 만들 수 없었습니다.
누군가 평신도의 차이점을 설명해 주시겠습니까?
답변
솔직히, 두 패턴은 실제로 매우 유사하며, 이들 사이의 정의 차이는 요청한 사람에 따라 달라지는 경향이 있습니다. 몇 가지 인기있는 선택은 다음과 같습니다.
- 상태는이를 포함하는 컨텍스트 객체에 대한 참조를 저장합니다. 전략은 그렇지 않습니다.
- 전략은 그렇지 않지만 국가는 스스로를 대체 할 수있다 (IE : 문맥 객체의 상태를 다른 것으로 바꾸는 것).
- 전략은 컨텍스트 개체에 매개 변수로 전달되는 반면 상태는 컨텍스트 개체 자체에 의해 생성됩니다.
- 전략은 하나의 특정 작업 만 처리하는 반면 상태는 컨텍스트 개체가 수행하는 모든 작업 (또는 대부분의 모든 작업)에 대한 기본 구현을 제공합니다.
“클래식”구현은 목록의 모든 항목에 대해 State 또는 Strategy와 일치하지만 둘을 혼합 한 하이브리드에서 실행됩니다. 특정 국가가 더 많은 국가 나 전략에 속하는지 여부는 궁극적으로 주관적인 질문입니다.
답변
- 전략 패턴은 전략의 요구에 따라 하나의 구현이 다른 사람을 대체 할 수 그래서, (기본적으로) 수행 다른 구현 같은 일을하는 것에 대한 정말. 예를 들어 전략 패턴에 다른 정렬 알고리즘이있을 수 있습니다. 개체에 대한 호출자는 사용되는 전략에 따라 변경되지 않지만 전략에 관계없이 목표는 동일합니다 (수집 정렬).
- 주 패턴은 모든 가능한 상태를 수용하는 부담에서 해방 발신자를 유지하면서, 상태에 따라 다른 일을 대한 것입니다. 예를 들어
getStatus()객체의 상태에 따라 다른 상태를 반환 하는
메소드가있을 수 있지만 메소드의 호출자는 각 잠재적 상태를 설명하기 위해 다르게 코딩 될 필요는 없습니다.
답변
차이점은 단순히 다른 문제를 해결한다는 것입니다.
- 주 패턴 상품의 어떤 객체가 (에)입니다 (주 또는 타입) – 그것은 반면, 상태에 의존하는 동작을 캡슐화
- 전략 패턴 거래 방법 객체가 특정 작업을 수행하는이 -이 알고리즘을 캡슐화합니다.
그러나 서로 다른 목표를 달성하기위한 구성은 매우 유사합니다. 두 패턴 모두 위임이있는 구성의 예입니다.
그들의 장점에 대한 관찰 :
사용하여 주 패턴을 국가 지주 (컨텍스트) 클래스의 지식 안도 어떤 상태 또는이고 무엇이 상태 또는 사용할 수있는 유형을 입력합니다. 이는 클래스가 OCP (Open-Closed Design Principal)를 준수 함을 의미합니다. 클래스는 상태 / 유형의 변화에 따라 닫히지 만 상태 / 유형은 확장 가능합니다.
전략 패턴 을 사용하면 알고리즘 사용 (컨텍스트) 클래스가 특정 작업 ( “알고리즘”)을 수행하는 방법 에 대한 지식이 없어집니다 . 이 경우에도 OCP를 준수합니다. 이 작업을 수행하는 방법에 대한 변경 사항은 클래스가 닫히지 만 디자인은이 작업을 해결하기 위해 다른 알고리즘을 추가 할 수 있습니다.
이는 컨텍스트 클래스의 단일 책임 원칙 (SRP) 준수를 향상시킬 수도 있습니다. 또한 알고리즘은 다른 클래스에서 쉽게 재사용 할 수있게됩니다.
답변
누군가 평신도의 용어로 설명해 주시겠습니까?
디자인 패턴은 실제로 “레이맨”개념은 아니지만 가능한 한 명확하게하기 위해 노력할 것입니다. 모든 디자인 패턴은 3 차원으로 고려 될 수 있습니다.
- 패턴이 해결하는 문제;
- 패턴의 정적 구조 (클래스 다이어그램)
- 패턴의 역학 (시퀀스 다이어그램).
상태와 전략을 비교해 봅시다.
패턴이 해결하는 문제
상태 는 두 경우 중 하나에 사용됩니다 [GoF book p. 306] :
- 객체의 동작은 상태에 따라 다르며 해당 상태에 따라 런타임에 동작을 변경해야합니다.
- 작업에는 개체의 상태에 따라 큰 여러 부분으로 된 조건문이 있습니다. 이 상태는 일반적으로 하나 이상의 열거 된 상수로 표시됩니다. 종종 여러 작업에 동일한 조건부 구조가 포함됩니다. State 패턴은 조건부의 각 분기를 별도의 클래스에 넣습니다. 이를 통해 객체 상태를 다른 객체와 독립적으로 변할 수있는 자체 객체로 취급 할 수 있습니다.
상태 패턴으로 해결되는 문제가 실제로 있는지 확인하려면 유한 상태 기계를 사용하여 객체의 상태를 모델링 할 수 있어야 합니다 . 여기 에서 적용된 예제를 찾을 수 있습니다 .
각 상태 전이는 상태 인터페이스의 방법입니다. 이는 디자인의 경우이 패턴을 적용하기 전에 상태 전이에 대해 확실해야 함을 의미합니다. 그렇지 않으면 전환을 추가하거나 제거하는 경우 인터페이스와 해당 전환을 구현하는 모든 클래스를 변경해야합니다.
나는 개인적 으로이 패턴을 유용하게 찾지 못했습니다. 룩업 테이블을 사용하여 유한 상태 머신을 항상 구현할 수 있습니다 (OO 방식은 아니지만 꽤 잘 작동합니다).
전략 은 다음 [GoF book p. 316] :
- 많은 관련 클래스는 동작이 다릅니다. 전략은 여러 가지 동작 중 하나를 사용하여 클래스를 구성하는 방법을 제공합니다.
- 알고리즘의 다른 변형이 필요합니다. 예를 들어, 다른 시공간 상충 관계를 반영하는 알고리즘을 정의 할 수 있습니다. 이러한 변형이 알고리즘의 클래스 계층으로 구현 될 때 전략을 사용할 수 있습니다 [HO87].
- 알고리즘은 클라이언트가 알아야 할 데이터를 사용합니다. 복잡한 알고리즘 별 데이터 구조가 노출되지 않도록 전략 패턴을 사용하십시오.
- 클래스는 많은 동작을 정의하며 동작에서 여러 조건문으로 나타납니다. 많은 조건부 대신 관련 조건부 분기를 자체 전략 클래스로 이동하십시오.
전략을 적용 할 마지막 경우는 조건부를 다형성 으로 바꾸기로 알려진 리팩토링과 관련이 있습니다.
요약 : 상태 및 전략은 매우 다른 문제를 해결합니다. 유한 상태 머신으로 문제를 모델링 할 수없는 경우 상태 패턴이 적절하지 않을 수 있습니다. 복잡한 알고리즘의 변형을 캡슐화하는 데 문제가 없다면 전략은 적용되지 않습니다.
패턴의 정적 구조
State 는 다음 UML 클래스 구조를 갖습니다.
전략 은 다음 UML 클래스 구조를 갖습니다.
요약 : 정적 구조와 관련하여이 두 패턴은 대부분 동일합니다. 사실, 다음과 같은 패턴을 검출 툴 이 하나는 그 “고려 에서 […] 동일한 패턴이다 (개념적 정보를 참조하지 않고, 예), 자동 공정에 의해 그 차이를 금지. 구조 “를
그러나 ConcreteStates가 자체적으로 상태 전이를 결정하는 경우 큰 차이가있을 수 있습니다 ( 위의 다이어그램에서 “” 결정할 수있는 “연관 “참조 ). 이로 인해 콘크리트 상태가 서로 연결됩니다. 예를 들어 (다음 섹션 참조) 상태 A는 상태 B 로의 전환을 결정합니다. 컨텍스트 클래스가 다음 구체적 상태로의 전환을 결정하면 이러한 종속성이 사라집니다.
패턴의 역학
위의 문제 섹션에서 언급 한 바와 같이, 국가는 일부에 따라 실행 시간에 그 동작 변경을 의미 상태 객체의를. 그러므로, 유한 상태 머신 의 관계에서 논의 된 바와 같이, 상태 천이 의 개념이 적용된다 . [GoF]는 전환이 ConcreteState 서브 클래스 또는 중앙 위치 (예 : 테이블 기반 위치)에서 정의 될 수 있다고 언급합니다.
간단한 유한 상태 머신을 가정 해 봅시다 :
서브 클래스가 다음 상태 객체를 반환하여 상태 전이를 결정한다고 가정하면 동적은 다음과 같습니다.
전략 의 역학을 보여주기 위해 실제 예제 를 빌리는 것이 유용합니다 .
요약 : 각 패턴은 상황에 따라 무언가를하기 위해 다형성 호출을 사용합니다. 상태 패턴에서 다형성 호출 (전환)은 종종 다음 상태를 변경합니다 . 전략 패턴에서 다형성 통화는 일반적으로 컨텍스트를 변경하지 않습니다 (예 : 신용 카드로 한 번 지불한다고해서 다음에 PayPal로 지불한다는 의미는 아닙니다). 다시, 상태 패턴의 동역학은 해당 패턴 상태 기계에 의해 결정되는데 , 이는이 패턴의 올바른 적용에 필수적입니다.
답변
전략 패턴에는 호스팅 클래스에서 알고리즘 구현을 이동하여 별도의 클래스에 배치하는 것이 포함됩니다. 이것은 호스트 클래스가 각 알고리즘 자체의 구현을 제공 할 필요가 없다는 것을 의미하며, 이는 부정한 코드로 이어질 수 있습니다.
정렬 알고리즘은 일반적으로 모두 같은 종류 (정렬)를 수행하므로 예제로 사용됩니다. 각각의 다른 정렬 알고리즘이 자체 클래스에 배치되면 클라이언트는 사용할 알고리즘을 쉽게 선택할 수 있으며 패턴은 액세스하기 쉬운 방법을 제공합니다.
상태 패턴은 객체의 상태가 변경 될 때 객체의 동작을 변경하는 것을 포함합니다. 이것은 호스트 클래스가 모든 다른 상태에 대해 동작 구현을 제공하지 않음을 의미합니다. 호스트 클래스는 일반적으로 주어진 상태에서 필요한 기능을 제공하는 클래스를 캡슐화하고 다른 클래스로 전환합니다. 상태가 바뀔 때
답변
고객 통화를 처리하는 IVR (Interactive Voice Response) 시스템을 고려하십시오. 고객이 다음을 처리하도록 프로그래밍 할 수 있습니다.
- 근무일
- 휴가
이 상황을 처리하기 위해 상태 패턴을 사용할 수 있습니다 .
- 휴일 : IVR은 단순히 ‘ 근무일 오전 9시에서 오후 5시 사이에 전화를받을 수 있습니다 ‘라고 응답합니다 .
- 근무일 : 고객을 고객 관리 담당 임원과 연결하여 응답합니다.
고객을 지원 임원과 연결하는이 프로세스 는 다음 중 하나를 기반으로 임원을 선택 하는 전략 패턴을 사용하여 구현할 수 있습니다 .
- 라운드 로빈
- 가장 최근에 사용한
- 다른 우선 순위 기반 알고리즘
전략 패턴 ‘을 결정 하는 방법을 몇 가지 작업을 수행 할’와 국가 패턴 ‘을 결정 하면 이를 수행 할’.
답변
전략은 시작 및 종료 결과는 동일하지만 내부적으로 다른 방법론을 사용하여 무언가를 “실행”하는 객체를 나타냅니다. 그런 의미에서 그들은 동사의 구현을 나타내는 것과 유사합니다. 상태 패턴 OTOH는 “상태”인 작업 상태 인 객체를 사용합니다. 그것들은 그 데이터에 대한 연산을 나타낼 수도 있지만 동사보다 명사를 표현하는 것과 더 유사하며 상태 머신에 맞게 조정됩니다.
