두 서비스가 내부에 있고 종속성 삽입 - 디자인 패턴 방식의 외관이 있습니다.

Question

두 서비스에서 거의 작동하지 않는 Facade 클래스를 만들고 싶습니다. 해당 서비스에 대한 문의는 프록시 클래스가 있습니다.

서비스 당 추상 프록시와 파생 프록시가있는 경우 -이 아키텍처 부분을 어떻게 작성하여 Facade에서의 해결을 피할 수 있습니까?

class Facade 
{ 
    private Proxy proxy1; 
    private Proxy proxy2; 

    public Facade() 
    { 
     //I don't like this part 
     proxy1 = ...Resolve<Proxy1Type>(); 
     proxy2 = ...Resolve<Proxy2Type>(); 
    } 


    public void Do() 
    { 
     proxy1.Call(); 
     proxy2.Call(); 
    } 
} 

    abstract class Proxy {public void Call();} 
    class Proxy1Type : Proxy {public void override Call(){}} 
    class Proxy2Type : Proxy {public void override Call(){}} 

이 사례를 해결하기 위해 어떤 디자인 패턴을 사용해야합니까?

편집은 선택적으로 나는이 솔루션에 가야하지만, 여전히 많은 그것을 좋아하지 않아

class Facade 
{ 
    private IProxy proxy1; 
    private IProxy proxy2; 

    //I feel it's still wrong 
    public Facade(IProxy1Type p1, IProxy2Type p2) 
    { 
     proxy1 = p1; 
     proxy2 = p2; 
    } 


    public void Do() 
    { 
     proxy1.Call(); 
     proxy2.Call(); 
    } 
} 
interface IProxy { void Call();} 
interface IProxy1Type : IProxy{} 
interface IProxy2Type : IProxy {} 
class Proxy1Type : IProxy1Type { public void Call() { } } 
class Proxy2Type : IProxy2Type { public void Call() { } } 

Answer 1

두 가지 정반대의 접근 방식은 당신이 질문에 둘 다 보여. 은 Service Locator (첫 번째 샘플) 또는 을 사용하여 클래스 내부에서 의존성을 해결할 수 있으며 Dependency Injection을 사용하여 외부에서을 삽입합니다.

의존성 삽입 (귀하의 경우 constructor injection)는 몇 가지 장점을 가지고있다 :

1. 그것은 당신이 알아낼 클래스 내부에 파고 필요하지 않기 때문에 Facade 클래스가 제대로 작동하기 위해 필요한 것을 더 분명 무엇 그것은 (언제) 해결하려고 노력할 것입니다.
2. 생성자를 통해 테스트 복식을 주입 할 수 있으므로 Facade 클래스를 단위 테스트하는 것이 더 쉽습니다. 단위 테스트에서 DI 컨테이너를 구성 할 필요가 없습니다.

서비스 로케이터에 대한 자세한 내용은 this post에서 읽을 수 있습니다 (사용하지 않는 이유는 무엇입니까?).