외관: 파사드 클래스는 응용 프로그램의 나머지 부분에서 패키지 1, 2 및 3을 추상화합니다. 클라이언트: 개체가 파사드 패턴을 사용하여 패키지의 리소스에 액세스합니다. 때로는 패턴이 간단한 시나리오에서 과도하게 사용될 수 있으며, 이로 인해 중복 구현이 발생할 수 있습니다. 이 두 가지 모두 고객이 알고 있는 호텔 및 플라이트 데이터 형식을 가지고 있습니다. 예를 들어 Facade와 동일한 패키지로 제공될 수 있습니다. Facade는 사용하기 쉽게 하위 시스템에 대한 통합된 상위 수준의 인터페이스를 정의합니다. 소비자는 카탈로그에서 주문할 때 외관을 접하게 됩니다. 소비자는 하나의 번호로 전화를 걸어 고객 서비스 담당자와 통화합니다. 고객 서비스 담당자는 Facade 역할을 수행하여 주문 이행 부서, 청구 부서 및 배송 부서에 대한 인터페이스를 제공합니다. 즉, Facade Pattern은 하위 시스템을 더 쉽게 사용할 수 있도록 하는 상위 수준 인터페이스를 설명합니다. 클라이언트가 걱정해야 할 것은 Facade 클래스입니다. 지금까지 디자인 패턴에서 우리는 이미 관찰자 및 어댑터 패턴을 살펴보았습니다.
외관은 어댑터와 몇 가지 유사점이 있으므로 시리즈의 논리적 다음 단계입니다. 외관의 개념은 인터페이스를 단순화하는 것인데, 서비스 지향 아키텍처는 외관 패턴을 사용합니다. 예를 들어 웹 서비스에서 하나의 웹 서비스는 외관에 의해 호출자로부터 숨겨진 여러 개의 작은 서비스에 대한 액세스를 제공할 수 있습니다. 마찬가지로 OSGi 번들의 일반적인 패턴은 번들의 사용자에게 노출되는 인터페이스 패키지를 제공하는 것입니다. 다른 모든 패키지는 사용자로부터 숨김이 있습니다. 훨씬 더 간단한 인터페이스 외에도 이 디자인 패턴을 사용하면 한 가지 더 많은 이점이 있습니다. 클라이언트 구현을 복잡한 하위 시스템에서 분리합니다. 따라서 기존 하위 시스템을 변경할 수 있으며 클라이언트에 영향을 주지 않습니다. 외관을 이해하기 위해 데스크톱 컴퓨터 의 매우 간단한 예를 들어 보자. 컴퓨터를 시작해야 할 때 시작 버튼을 누르기만 하면 됩니다. 우리는 정말 모든 것이 컴퓨터 하드웨어 및 소프트웨어 내부에 가서 상관하지 않습니다.
그것은 외관 패턴의 예입니다. 또 다른 좋은 예는 컴퓨터의 시작일 수 있습니다. 컴퓨터가 시작되면 CPU, 메모리, 하드 드라이브 등의 작업이 포함됩니다. 사용자가 쉽게 사용할 수 있도록 작업의 복잡성을 감싸는 외관을 추가하고 대신 하나의 간단한 인터페이스를 제공할 수 있습니다. 외관 디자인 패턴도 마찬가지입니다. 시스템의 복잡성을 숨기고 클라이언트가 시스템에 액세스할 수 있는 클라이언트에 대한 인터페이스를 제공합니다. 답변: 아니요! 어댑터 패턴은 하나 이상의 클래스의 인터페이스를 클라이언트가 기대하는 하나의 인터페이스로 변경합니다. 대부분의 교과서 예제에서는 어댑터가 한 클래스에 적응하는 것을 보여 주지만 클라이언트가 코딩된 인터페이스를 제공하기 위해 많은 클래스를 조정해야 할 수 있습니다. 마찬가지로 Facade는 매우 복잡한 인터페이스를 가진 단일 클래스에 단순화된 인터페이스를 제공할 수 있습니다. 둘 사이의 차이점은 그들이 “래핑”얼마나 많은 클래스의 관점에서하지 않습니다, 그것은 그들의 의도에있다. 그래서, 간단히 말해서, 외관은 일을 더 깨끗하고 더 매력적으로 보이게하는 것을 목표로합니다.
Facade는 단일 인터페이스 개체 내에서 복잡한 하위 시스템을 캡슐화하는 것에 대해 설명합니다. 이렇게 하면 하위 시스템을 성공적으로 활용하는 데 필요한 학습 곡선이 줄어듭니다.
