프로토콜이나 외부 리소스 형식과 같은 "저수준"유형 매개 변수를 기반으로 사용자에게 추상 기본 클래스 구현을 반환하는 공장이있는 상황에서 항상 유혹을 받는다. 추상 클래스를 내부 "전략 팩토리"가있는 구체적인 클래스로 변환하여 사용자가 구현 유형을 생성자에 전달하고 직접 기본 클래스로 작업 할 수 있도록합니다.구체적인 클래스에서 상속 계층 구조를 숨기는 이유는 무엇입니까?
닷넷 프레임 워크가 SocketType을 구현하는 대신 DatagramSocket을 만드는 대신 소켓을 구현하기로 결정했다. 계층을 하나의 구체적인 클래스로 병합하는 것이 언제 받아 들일 수 있는지를 결정하기위한 지침은 무엇입니까?
"요점은 클라이언트가 알고 있어야하는 저수준 세부 사항의 양"이라고 생각합니다.
첫 번째 솔루션 (추상 기본 클래스)을 선택하면 클라이언트 클래스에 대한 자세한 정보가 숨겨집니다. 이렇게하면 클라이언트는 낮은 수준의 세부 사항 (프로토콜, 외부 리소스의 형식)을 완전히 무시할 수 있습니다. 구현의 세부 사항과 구현 내에서 사용되는 유형을 완전히 숨기는 것이 목표 인 경우이 방법을 선호합니다.
클라이언트가 이미 저수준 구현의 일부 세부 사항을 알고 있다면 (예를 들어 클라이언트가 사용할 소켓이 UDP이고 그와 같은 정보를 알고 싶어하는 경우) 추상 기본 클래스 접근법은 내부 "전략 공장"으로 대체 될 수 있습니다.
'상속보다 구성을 선호합니다'라는 생각에서 나는 항상 상속보다 전략 + 공장 방법을 선택합니다. 이것은 두 가지 장점을 제공합니다 : * 대부분의 경우 각 전략은 그것을 사용할 클래스에 대해 신경 쓰지 않고 독립적으로 테스트 할 수 있습니다. * 동일한 클래스에서 클라이언트 클래스는 모의 전략 *으로 테스트 할 수 있습니다. 예를 들어 데코레이터 패턴을 사용하여 전략을 구성 가능하도록 디자인 할 수 있습니다.이 패턴은 하위 클래스의 폭발을 일으키지 않으면 서 많은 유연성을 제공합니다.
전체적으로, 모든 하위 클론의 외부 의미가 (필요한 경우) 동일하면 전략 경로를 따르십시오.