1700470010
1700470011
}
1700470012
1700470013
}
1700470014
1700470015
只是增加了一个letterPolice变量的声明以及一个方法的调用，那这个写信的过程就变成这样：先写信、写信封，然后警察开始检查，之后才把信放到信封，最后发送出去，那这个变更对客户来说是透明的，他根本就看不到有人在检查他的邮件，他也不用了解，反正现代化的邮件系统都帮他做了，这也是他乐意的地方。
1700470016
1700470017
场景类还是完全相同，但是运行结果稍有不同，如下所示：
1700470018
1700470019
填写信的内容……Hello,It’s me,do you know who I am?I’m your old lover.I’d like to……
1700470020
1700470021
填写收件人地址及姓名……Happy Road No.666，God Province,Heaven
1700470022
1700470023
com.cbf4life.common3.LetterProcessImpl@15ff48b信件已经检查过了……
1700470024
1700470025
把信放到信封中……
1700470026
1700470027
邮递信件……
1700470028
1700470029
高层模块没有任何改动，但是信件却已经被检查过了。这正是我们设计所需要的模式，不改变子系统对外暴露的接口、方法，只改变内部的处理逻辑，其他兄弟模块的调用产生了不同的结果，确实是一个非常棒的设计。这就是门面模式。
1700470030
1700470031
1700470032
1700470033
1700470034
设计模式之禅 [:1700454026]
1700470035
设计模式之禅 23.2 门面模式的定义
1700470036
1700470037
门面模式（Facade Pattern）也叫做外观模式，是一种比较常用的封装模式，其定义如下：
1700470038
1700470039
Provide a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）
1700470040
1700470041
门面模式注重“统一的对象”，也就是提供一个访问子系统的接口，除了这个接口不允许有任何访问子系统的行为发生，其通用类图，如图23-4所示。
1700470042
1700470043
1700470044
1700470045
1700470046
图23-4 扩展后的系统类图
1700470047
1700470048
是的，类图就这么简单，但是它代表的意义可是异常复杂，Subsystem Classes是子系统所有类的简称，它可能代表一个类，也可能代表几十个对象的集合。甭管多少对象，我们把这些对象全部圈入子系统的范畴，其结构如图23-5所示。
1700470049
1700470050
1700470051
1700470052
1700470053
图23-5 门面模式示意图
1700470054
1700470055
再简单地说，门面对象是外界访问子系统内部的唯一通道，不管子系统内部是多么杂乱无章，只要有门面对象在，就可以做到“金玉其外，败絮其中”。我们先明确一下门面模式的角色。
1700470056
1700470057
❑Facade门面角色
1700470058
1700470059
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。