전략 패턴

Question

다른 클라이언트에 API를 구현해야합니다. 각 클라이언트에 대한 구현은 다릅니다. 그래서 groovy (Java와 비슷한)에서 전략 패턴을 사용하여 인터페이스를 구현할 생각이고 각 클라이언트에 대해 (인터페이스를 구현하는) 클래스를 만들고 UI를 사용하여 클래스를 호출하도록 구성하려고합니다. (클래스의 드롭 다운 선택).

interface PricingStrategy { 


} 



class CanadaPricingStrategy implements PricingStrategy { 

    Method 1... 
    Method 2... 

} 

class BrazilPricingStrategy implements PricingStrategy { 

    Method 1... 
    Method 2... 

} 

는 그렇게 할 수있는 가장 좋은 방법이 될 것인가 아니면 변수로 폐쇄를 사용하여 플러그 - 행동 방식을 사용할 수 있습니까?

Answer 1

폐쇄 형을 변수로 사용하여 플러그 가능 동작 접근법을 사용할 수 있습니까?

요구 사항에 대해 더 알지 못해도 말할 수 없지만 일반적으로 설명 된 인터페이스 기반 접근 방식은 의미가 있습니다. 그것은 여전히 ​​플러그 가능할 수 있습니다. 각 구현에 대해 별도의 플러그인을 갖고있는 것처럼 할 수 있고 앱의 다른 버전을 다양한 동작을 제공하는 다양한 플러그인으로 구축 할 수 있습니다. 클래스 경로에있는 PricingStrategy 구현을 모두로드하는 동적 발견 메커니즘을 사용할 수 있습니다. 많은 옵션이 있지만 요구 사항에 대한 정보가 거의 없기 때문에 인터페이스 기반 접근 방식이 탄탄한 출발점이라고 말할 수 있습니다.

Answer 2

나는 아래에 언급 된 문장에 따라 두 부분으로 문제 문을 나눕니다 :

1. 다른 클라이언트 API를 구현하려면.
2. 그리고 각 클라이언트에 대한 구현이 다릅니다.

두 지점마다 나는 두 개의 서로 다른 디자인 패턴을 사용하여 문제 문을 구현하는 방법을 제안합니다으로 :

1. 어댑터 디자인 패턴 : API는 항상 어댑터 디자인 패턴 소스 인해를 사용하여 설계되어야한다 클라이언트 인터페이스는 호환되지 않을 수 있으며이 디자인 패턴은 호환되지 않는 인터페이스를 클라이언트가 필요로하는 다른 인터페이스로 변환합니다. 이 유형의 사례는 양측에서 다양한 기술, 매개 변수 등 여러 상황으로 인해 API 디자인에서 항상 발생합니다.

2. 전략 디자인 패턴 : 내부 다른 클라이언트의 논리 구현이 다릅니다. 따라서 전략 패턴의 도움을 받아이를 설계해야합니다.

그리고이 전략 패턴을 어댑터 디자인 패턴이라고 부릅니다.