文档介绍：外观模式
外观模式
模式动机与定义
模式结构与分析
模式实例与解析
模式效果与应用
模式扩展
装饰模式
模式动机
在现实生活中，存在如下一些场景：
想组装一台新电脑，一个方案是去电子市场把自己需要的配件都买回来，然后自己组装，但需要对各种配件都要比较熟悉，这样才能选择最合适的配件，而且还要考虑配件之间的兼容性；另外一个方案，就是到电子市场，找一家专业装机的公司，把具体的要求一讲，然后就等着拿电脑就好了，方案二不需要挨家去跑，也不需要熟悉各种配件，通常是大多数人的选择。
餐厅、茶馆，厨师、茶艺师
外观模式
模式动机
客户完全自己组装电脑
找专业的装机公司组装电脑
外观模式
模式动机
我们把组装电脑的过程抽象一下：如果把电子市场看成是一个系统，而各个卖配件的公司看成是子系统的话，就类似于出现了这样一种情况：客户端为了完成某个功能，需要去调用某个系统中的多个子系统，简称为子系统A、子系统B和子系统C，对于客户端而言，那就需要知道A、B、C这三个子系统的功能，还需要知道如何组合A、B、C这三个子系统所提供的功能来实现自己所需要的功能，非常麻烦。
方案二提供了一种简单的方法，能让客户端实现相同的功能却不需要跟系统中的多个模块交互。
外观模式
模式动机
方案二引入的装机公司，就是所谓的外观角色，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。
外观模式
模式定义
外观模式(Facade Pattern)：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
外观模式中，一个子系统的外部与其内部的通信通过一个统一的外观类进行，外观类将客户类与子系统的内部复杂性分隔开，使得客户类只需要与外观角色打交道，而不需要与子系统内部的很多对象打交道。
外观模式又称为门面模式，它是一种对象结构型模式。
外观模式是迪米特原则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。
外观模式
模式结构
外观模式示意图
外观模式类结构图
装饰模式
装饰模式包含如下角色
Facade：外观角色，客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应子系统去，传递给相应的子系统对象处理。
SubSystem：子系统角色，在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。
模式分析
外观模式的主要目的在于降低系统的复杂程度，在面向对象软件系统中，类与类之间的关系越多，不能表示系统设计得越好，反而表示系统中类之间的耦合度太大，这样的系统在维护和修改时都缺乏灵活性，因为一个类的改动会导致多个类发生变化，而外观模式的引入在很大程度上降低了类与类之间的耦合关系。引入外观模式之后，增加新的子系统或者移除子系统都非常方便，客户类无须进行修改（或者极少的修改），只需要在外观类中增加或移除对子系统的引用即可。从这一点来说，外观模式在一定程度上并不符合开闭原则，增加新的子系统需要对原有系统进行一定的修改，虽然这个修改工作量可能不大。
外观模式
模式分析
外观模式中所指的子系统是一个广义的概念，它可以是一个类、一个功能模块、系统的一个组成部分或者一个完整的系统。子系统类通常是一些业务类，实现了一些具体的、独立的业务功能，例如：
外观模式