标签：对象 带来 依赖 帮助 单元测试 数据库操作 strong 系统 ref
门面模式也叫外观模式，是一种比较常用的封装模式，其定义如下:
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就是说该角色没有实际的业务逻辑，只是一个委托类。
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。
想想看，如果我们不使用门面模式，外界访问直接深入到子系统内部，相互之间是一种强耦合关系，你死我就死，你活我才能活，这样的强依赖是系统设计所不能接受的，门面模式的出现就很好地解决了该问题，所有的依赖都是对门面对象的依赖，与子系统无关。
依赖减少了，灵活性自然提高了。不管子系统内部如何变化，只要不影响到门面对象，任你自由活动。
想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，你休想访问到。
门面模式最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放。一旦在系统投产后发现有一个错误，你怎么解决？完全遵从开闭原则，根本没办法解决。继承？覆写？都顶不上用，唯一能做的一件事就是修改门面角色的代码，这个风险相当大，这就需要大家在涉及的时候慎之又慎，多思考几遍才会有好收获。
比如一个纯洁的门面对象已经超过了200行的代码，虽然都是非常简单的委托操作，也建议拆分成多个门面，否则会给以后的维护和扩展带来不必要的麻烦。那么怎么拆分？按照功能拆分是一个非常好的原则，比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等。
我们以门面模式的通用源代码为例。ClassA、ClassB、ClassC是一个子系统中的3个对象，现在有两个不同的高层模块来访问该子系统，模块一可以完整的访问所有业务逻辑，也就是通用代码中的Facade类，它是子系统的信任模块;而模块二属于受限访问对象，只能访问methodB方法，那该如何处理呢？在这种情况下，就需要建立两个门面以供不同的高层模块来访问，在原有的通用源码上增加一个新的门面即可。
在门面模式中，门面角色应该是稳定，它不应该经常变化，一个系统一旦投入运行它就不应该被改变，它是一个系统对外的接口，你变来变去还怎么保证其他模块的稳定运行呢？但是，业务逻辑是会经常变化的，我们已经把它的变化封装在子系统内部，无论你如何变化，对外界的访问者来说，都还是同一个门面，同样的方法–这才是架构师最希望看到的结构。
门面模式是一个很好的封装方法，一个子系统比较复杂时，比如算法或者业务比较复杂就可以封装出一个或多个门面出来，项目的结构简单，而且扩展性非常好。还有，对于一个较大项目，为了避免人员带来的风险，也可以使用门面模式，技术水平比较差的成员，尽量安排独立的模块，然后把他写的程序封装到一个门面里，尽量让其他项目成员不用看到这些人的代码，看也看不懂。使用门面模式后，对门面进行单元测试，约束项目成员的代码质量，对项目整体质量的提升也是一个比较好的帮助。
代码例子:
https://github.com/developers-youcong/DesignPatternPractice
标签：对象 带来 依赖 帮助 单元测试 数据库操作 strong 系统 ref
原文地址：https://www.cnblogs.com/youcong/p/12590272.html
