入門
プロジェクトの開発では、時には我々はこのような状況に遭遇：ビジネスニーズの発展に伴い、既存のシステムの様々なサブシステム間の比較的緊密な結合を持っています。今、携帯端末用のサービス処理を提供し、これらのサブシステムの機能を使用しています。どのように我々は、このようなビジネスニーズに対処するためにありますか？つまり、この章のFacadeパターンで問題が解決されます。
正式な交渉に入る前に、まずビジネスニーズとして対応する2つの方法を分析します。
モード：以下に示すように、呼び出し元の関数のサブシステムに直接各移動端末は、密結合関係は、各サブシステムの間に形成されています。
第二の方法：高レベルのインターフェイス、インターフェイスは、高レベルのインタラクションサブシステムを担当して、以下に示すように、移動端末へのインターフェースは、使用する必要が提供されます。
構造は二つの方法、携帯端末上の図からわかるように、第2のアプローチは、モバイルクライアントは、各サブシステムのロジックを知っている必要はありません。第二のアプローチのように、モードを使用するよりはるかに簡単で、かつ高いだけ必要ですその上でインタラクティブなインターフェース。実際、第二の方法は、我々は、モデルの外観を言うためにここにいるものです。
定義
「サブシステムは、統一されたインターフェースにインターフェースのセットを提供する。ファサードパターンを使用するサブシステムが容易になり、より高いレベルのインタフェースを定義しています。」
オリジナルの定義は、「デザインパターン」（アディソン・ウェズリー、1994）に登場しました。
この定義は、上記の導入を説明するための例示のために、それはよく理解して、ここで定義の中で二つの重要な役割を分析する必要があります。
外観役割は：イラストは、「高レベルのインタフェース」の紹介です、クライアントがこの役割のメソッドを呼び出すことができます。また、役割と責任は、既知の機能をサブシステムに関連付けられています。
役割をサブシステム：同時に、1つまたは複数のサブシステムがあるかもしれません。各サブシステムは、単一のクラスではなく、クラスのセット。各サブシステムは、直接クライアント、またはロールと呼ばれているの外観を呼び出すことができます。
Structureチャート
例
そのような夕食のためにレストランに行くなど、多くのモデルの外観のアプリケーションのライフ例は、我々だけで対話する必要が食品材料の選択、調理や他のプロセス、およびウェイターに焦点を当てていない：ウェイターは私たちのレシピ（インタフェースモードの排他的な外観に相当）を得ました、我々は（コール・インタフェース）、あなたは食べ物を楽しむことができる料理を選びました。
这里，我们用另一个生活中的例子来进行解说。不知道大家有没有通过旅行社报团出去旅游的经历？这是一个很好的外观模式的应用。我们选择好景点之后，旅行社会帮我们联系大巴、旅馆、饭店、景点门票以及景点服务等事情，这些事情我们都不需要亲自去安排，这就是外观模式的便利之处：可以使得客户端的接口更简单。
下面列出应用外观模式实现旅行社报团旅游的结构图：
如果不应用外观模式，我们(上图中的Client)，就得自己去联系交通工具、预定旅馆、饭馆、景点门票等，相信这样的旅程，大家会感觉很累。有了外观角色(上图中的Facade)，它会帮我们去处理这些事情。完整代码大家可以下载查看，这里只贴出部分源码。
Facade.m(部分源码)：
1 - (id)init 2 { 3 self = [super init]; 4 if (self != nil) 5 { 6 _transportation = [[Transportation alloc] init]; 7 _hotel = [[Hotel alloc] init]; 8 _restaurant = [[Restaurant alloc] init]; 9 _attractions = [[Attractions alloc] init]; 10 } 11 return self; 12 } 13 14 - (void)travel 15 { 16 [_transportation selTransportation]; 17 [_hotel selHotel]; 18 [_restaurant selRestaurant]; 19 [_attractions selAttractions]; 20 } 21 22 - (void)dealloc 23 { 24 [_transportation release]; 25 [_hotel release]; 26 [_restaurant release]; 27 [_attractions release]; 28 29 [super dealloc]; 30 }
从源码可以看到，外观类调用了交通工具类、旅馆类、饭馆类、景点类。下面看看客户端调用代码：
1 Facade *facade = [[Facade alloc] init]; 2 [facade travel]; 3 [facade release];
客户端代码只需要和外观类进行交互。
小结
通过上面的讲解，我们来分析一下外观模式的特点：
- Facade设计模式注重从架构的层次去看整个系统，而不是单个类的层次。很多时候，它是一种架构设计模式，比如我们常用的三层架构。
- Facade模式简化了整个系统的接口，同时对于系统内部(子系统)与外部程序(Client)来说，也达到了一种“解耦”的效果。
根据外观模式的特点，我们可以在以下情况中使用Facade模式：
- 不需要使用一个复杂系统的所有功能，只需要使用系统的部分功能时，那么应用Façade模式提供一个高层接口将比直接调用原系统的接口简单得多。
- 希望封装或者隐藏原系统的接口时，可以考虑使用外观模式。
- 希望使用原系统的部分功能，而且还希望增加一些新的功能。
- 构建一个具有层次结构的子系统时，使用Facade模式定义子系统中每层的高级接口。如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
转载于:https://www.cnblogs.com/eagle927183/p/3511876.html