一. 外观模式
1. 背景
在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了。
软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了“开闭原则”，也违背了“迪米特法则”，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标。
2. 定义和特点
(1). 定义
是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
(2). 优点
A. 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
B. 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
C. 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
(3). 缺点
A. 不能很好地限制客户使用子系统类。
B. 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
3. 具体实现
(1). 模式结构
A. 外观角色：为多个子系统对外提供一个共同的接口。
B. 子系统角色：实现系统的部分功能，客户可以通过外观角色访问它。
C. 客户端：通过一个外观角色访问各个子系统的功能。
结构图如下：
(2). 使用场景
见下面代码。
(3). 代码实操
子系统代码
/// <summary> /// 子业务类1 /// </summary> public class ChildService1 { public void MyHandler1() { Console.WriteLine("我正在处理业务1"); } } /// <summary> /// 子业务类2 /// </summary> public class ChildService2 { public void MyHandler2() { Console.WriteLine("我正在处理业务2"); } } /// <summary> /// 子业务类3 /// </summary> public class ChildService3 { public void MyHandler3() { Console.WriteLine("我正在处理业务3"); } }