외관 패턴 - 요청 흐름

Question

나는 Facade 패턴이 복잡한 서브 시스템 상호 작용을 숨김으로써보다 간단한 인터페이스를 제공한다는 것을 알고 있습니다.

내가 Facade 패턴에 아래 위키 피 디아 UML 말하는거야 :

은 통신인가/외관에 대한 호출은 단방향 요청은 클라이언트 1/클라이언트 2가 요청을 전송하고 수신, 즉이다 응답 Facade에서 하지만 Facade는 Client1/Client2에 요청을 시작할 수 없습니까? 시스템/클래스를 통해 상호 작용 - 중재자가 양방향 (> 중재자 클라이언트에게 <)를 용이로 (간단한 인터페이스) 요청의 상호 작용 -

외관은 단방향 (> 외관 클라이언트)를 제공한다는 말에 나는 수정이 있습니까?

이 시점을 강조하는 자료를 제공 할 수 있습니까?

Answer 1

예, 당신은 모두 정확합니다. 여기 GoF 책 282 쪽 (중점 광산)의 직접 인용문이 있습니다.

Facade는 더 편리한 인터페이스를 제공하기 위해 객체 서브 시스템 을 추상화한다는 점에서 Mediator와 다릅니다. 그것의 프로토콜은 단방향입니다; 즉, Facade 객체는 서브 시스템 클래스의 요청을하지만 그 반대는 아닙니다. 대조적으로 Mediator는 동료 개체가 제공하지 않는 협력 동작을 허용하거나 은 제공 할 수 없으며 프로토콜은 다 방향입니다. 중재자는 행동 패턴 반면

또한 외관이 구조 패턴으로 분류되어 있습니다. Facade가 요청을 시작할 수 있다면, 행동을 취하게 될 것입니다.

Answer 2

(1) 통신/외관에 대한 호출이 요청, 즉 단방향입니다 있습니까 만 클라이언트 1/클라이언트 2는 요청을 보내고 외관에서 응답을받을 수 있지만, 외관 요청을 시작할 수 없습니다 ~ Client1/Client2?

수정. 그래서 그들이 고객으로 알려져 있습니다. Facade 클래스는 클라이언트를 위해 작업을 수행하는 실제 서버 (웹 서버 이야기와 불필요하게 섞이지 않음)입니다. Facade는 클라이언트가 실제로 어떤 일이 발생 하는지를 알 필요가 없지만 높은 수준의 추상화 만 알면 의미가 있습니다.

예 : 난 그냥 room.powerOff();를 호출 할 클라이언트로이 예에서

public class Bulb{ 

    public void on(){ 
     //logic to turn on the bulb. 
    } 

    public void off(){ 
     //logic to turn off the bulb. 
    } 

} 

public class Fan{ 

    public void on(){ 
     //logic to turn on the fan. 
    } 

    public void off(){ 
     //logic to turn off the fan. 
    } 

} 

public class Room{ 

    private Bulb bulb; 
    private Fan fan; 

    public void powerOff(){ 
     this.bulb.off(); 
     this.fan.off(); 
    } 
} 

. 나는 내부적으로 일어나는 것에 관심이 없다.

(2)는 외관 단방향 (클라이언트 -> 외관) 제공하는 말에 수정이 있습니까 중재자로 은 양방향 용이 (간단한 인터페이스) 요청의 상호 작용 (< 클라이언트 -> 중재자) 상호 작용을 시스템/수업 전반에 걸쳐?

(a) Facade는 단방향 (클라이언트 -> Facade) 요청 상호 작용 (더 간단한 인터페이스로) -> 정답을 제공합니다.

(b) 중재자는 양방향 (클라이언트 < -> 중재자) 상호 작용 -> 수정을 용이하게합니다. 이것은 클라이언트가 서브 시스템 (Facade에서)과 같은 것입니다. :))