introduction
In project development, sometimes we encounter such a situation: With the development of business needs, have a relatively tight coupling between the various subsystems of existing systems. Now use the functions of these subsystems, providing service processing for the mobile terminal. How are we to deal with such business needs? That is the problem in this chapter Facade pattern to be solved.
Before entering the formal talks, we will first analyze two ways to respond as business needs:
A mode: each mobile terminal directly to the calling function subsystem, tight coupling relationship is formed between each subsystem, as shown below:
Second way: a high-level interface, and the interface is responsible for high-level interaction subsystem, provides an interface to the mobile terminal needs to use, as shown below:
Structure can be seen from FIG above two methods, the mobile terminal, the second approach is much easier to use than a mode, as in the second approach, the mobile client does not need to know the logic of each subsystem, and requires only high interactive interface on it. Indeed Second way, is what we are here to say the appearance of the model.
definition
"Subsystem provides a set of interfaces in a unified interface. Facade pattern defines a higher-level interface that makes the subsystem easier to use."
Original definition appeared in "Design Patterns" (Addison-Wesley, 1994).
This definition, by way of illustration to explain the introduction of the above, it should be well understood, and then analyze here two important roles in the definition:
Appearance role: the illustration is the introduction of "high-level interface", the client can call methods this role; Additionally, the roles and responsibilities associated with known function subsystem.
Subsystem roles: There may be one or more subsystems simultaneously. Each subsystem is not a single class, but rather a set of classes. Each subsystem can be directly call the client, or the appearance of being called role.
Structure chart
Examples
Life examples of the application of the appearance of many models, such as go to a restaurant for dinner, we do not focus on food choice of materials, cooking and other processes, and the waiter just need to interact: the waiter gave us the recipe (the equivalent of the exclusive appearance of the interface mode), we chose dishes (call interface), you can enjoy the food.
这里，我们用另一个生活中的例子来进行解说。不知道大家有没有通过旅行社报团出去旅游的经历？这是一个很好的外观模式的应用。我们选择好景点之后，旅行社会帮我们联系大巴、旅馆、饭店、景点门票以及景点服务等事情，这些事情我们都不需要亲自去安排，这就是外观模式的便利之处：可以使得客户端的接口更简单。
下面列出应用外观模式实现旅行社报团旅游的结构图：
如果不应用外观模式，我们(上图中的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