디자인 패턴 비교

Question

저는 C#을 사용하여 디자인 패턴을 학습하고 있습니다. 내가 직면하고있는 도전 과제 중 하나는 비슷한 것처럼 보입니다. 당신이 그들을 구별하도록 도와 주시겠습니까 - 기본적으로 언제 사용합니까? 왜 다른데?

1. 브리지 및 전략
2. 주 및 전략
3. 외장 및 전략
4. 복합 및 전략

내가 웹에서 사용할 수있는 자원이 많이 있다는 것을 알고 있습니다. 그러나 그들은이 특별한 시나리오를 다루지 않습니다.

[참고 : 선택 사항의 구현 예와 그 이유를 찾고 있습니다. 단순한 설명이 아님]

---

답장을 보내 주셔서 감사합니다. 다리를 더 배우려고 시도했습니다.

다음과 같은 경우가 있습니다.

내 방에는 두 개의 TV가 있습니다. 각각 하나의 리모컨이 있습니다. 두 가지 모두 사용자가 사용할 수있는 인터페이스가 동일합니다. 그러나 나는 두 리모컨 중 하나의 프로세서를 사용할 자체 원격 제어 장치를 갖고 싶습니다.

다음 코드가 있습니다. 제 생각에는 이것이 전략 패턴입니다. 이걸 Bridge로 변환하고 싶습니다.

1. Bridge로 변환하는 방법은 무엇입니까?

2. Bridge로 변환하면 어떤 이점이 있습니까?

   공용 클래스 PhilliTV { 공공 무효)의 (시작 { Console.WriteLine ("PhilliTV 바간"); } }

   public class SonTV 
       { 
        public void Initiate() 
        { 
         Console.WriteLine("SonTV Initiated"); 
        } 
       } 
   
   
   
   
       public class SonRemote : IRemote 
       { 
        SonTV stv = new SonTV(); 
        public void Play() 
        { 
         stv.Initiate(); 
        } 
       } 
   
   
   public class PhilliRemote : IRemote 
       { 
        PhilliTV ptv = new PhilliTV(); 
        public void Play() 
        { 
         ptv.Begin(); 
        } 
       } 
   
   
       public class URemoteConsumer 
       { 
        IRemote remote = new PhilliRemote(); 
   
        public void MyPlay() 
        { 
         remote.Play(); 
        } 
   

Answer 1

나는이 일을 위해 헤드 퍼스트 디자인 패턴을 추천 할 수 있습니다. 그 책에서 :

국가와 전략의 차이점은 의도 된 것입니다. State 패턴을 사용하면 객체 수명 동안 동작을 동적으로 변경합니다. 이 클래스는 if 문 대신 사용할 수 있습니다. 전략 패턴을 사용하면 일반적으로 객체가 생성 될 때 한 번 수행합니다. 서브 클래 싱을위한 대안입니다. 동작은 유연하지만, 주어진 객체의 경우 한 번 구성합니다.

외관과 전략은 서로 관련이 없습니다. 이 전략은 런타임에 동작 (구현)을 구성하기위한 것입니다. Facade는 기존 인터페이스를 단순화합니다. 복잡한 ATM 시스템을 사용하는 경우 2 개의 인터페이스가 필요할 수 있습니다. 오류 등을 처리하는 방법에 대한 모든 종류의 방법과 프론트 엔드에 의해 호출되는 방법을 포함하여 모든 기능을 갖춘 것이 더 간단 할 수 있습니다. 프론트 엔드 코드는 오류를 처리하는 방법을 알 필요가 없으며 다른 곳의 오류 처리기가이를 처리합니다. 은이라는 오류 만 알면됩니다. 간소화 된 인터페이스 (시간이 지남에 따라 더 많은 상수가되기를 바랍니다)는 프런트 엔드 개발자의 삶을 더 단순하게 만들고 변경 가능한 요소를 숨 깁니다.그것이 당신이 Facade를 만들 때입니다. 모든 기능을 갖춘 인터페이스가 있지만 대부분의 사람들은 하위 집합 만 사용합니다. 그 부분 집합이 Facade가 될 것입니다.

복합 패턴을 사용하면 개체를 트리 구조로 구성 할 수 있습니다. 전략 패턴과의 차이를 어떻게 볼 수 없는지 나는 알 수 없습니다. 그들은 공통점이 거의 없습니다.

아마도 이러한 패턴의 실제 사용의 몇 가지 생각 :

• 다리 데이터 모델이 아직 명확하지 않다. 대부분의 구현은 자체 호출로 구현합니다. 그렇게하면 추상화가 여전히 불확실하더라도 구현의 적절한 부분을 만들 수 있습니다.
• 상태는 제한된 양의 상태가있을 때 일반적으로 사용되며 동작이 뚜렷하게 다릅니다. 나는 여기 커피 기계와 프린터를 생각하고있다. 잔액이 0보다 작 으면 빼기 (금액)가 항상 오류를 생성 할 수있는 은행 시스템을 구현할 수 있습니다.
• 외관은 흔하지 않습니다. 비즈니스 프로세스와 유지 보수 프로세스에서 사용하는 메소드가있는 API가있는 데이터 레이어 (예 : 최대 절전 모드)가있을 수 있습니다. 그런 다음 두 개의 간단한 API를 정의 할 수 있습니다. 하나는 비즈니스 개발자 용이고 다른 하나는 유지 관리 개발자 용입니다. 이러한 API는 물론 완전한 API를 호출하지만 비즈니스 개발자로는 볼 수 없습니다.
• 전략은 Spring이나 다른 형태의 IoC를 사용하는 경우 가장 일반적이며, Junit 테스트의 경우 대개 대체 "데이터베이스"레이어도 삽입해야합니다.
• 복합 패턴은 GUI 응용 프로그램에서 가장 많이 사용됩니다. 지금 다른 유스 케이스를 생각할 수 없습니다.

나는 다양한 패턴을 인터뷰 했으므로 Head First Design Patterns를 정말 추천합니다. 그런 다음 패턴이 자신에 대해 조금 말하며 모든 패턴 중에서 왜 가장 좋은 패턴인지 알 수 있습니다.

Answer 2

상태와 전략 : 상태에서 사용할 알고리즘을 결정하는 것은 개체입니다 (해당 알고리즘에 따라 다름). 현재 상태), 전략에서 클라이언트는 어떤 알고리즘을 사용할 것인지를 제어합니다.

Answer 3

"..it is the object who is in control of deciding which algorithm to use.." is not so clear (to me, at least).

가 상태 포인터를 가지고 객체는,의는 "currentState를"포인터를 가정 해 봅시다. 모든 상태는 동일한 인터페이스를 지원하고 메서드 A, B 및 C (예 : 메서드)를 처리하는 방법을 알고 있습니다. 이 currentState.A 트리거(), currentState.B() 또는 currentState.C() -

개체가 어떤 방식 (주 인터페이스에 의해 노출 된 A, B 또는 C)을 수행 할 필요

.

실제 처리는 각 상태에서 수행됩니다. 이렇게하면 우리 자신의 상태를 결정하기 위해 여러 개의 if-else 조건을 사용하지 않아도됩니다.