外观模式
系统间耦合的复杂度
动机or背景
- 上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战。
- 如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦合?
模式定义
为子系统中的一组接口提供一个一致(稳定)的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用(复用)。
结构
举例
其实,外观模式并没有特定代码结构,更多的体现出的是一种原则和思想,即在子系统中“解耦合”。在这里就不提供明确的举例代码。
要点总结
- 从客户程序的角度来看,外观模式简化了整个组件系统的接口,对于组件内部和外部客户程序来说,达到了一种“解耦合”的效果–内部子系统的任何变化不会影响到外观接口变化。
- 外观设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。外观模式很多时候更是一种架构设计模式。
- 外观设计模式并非一个集装箱,可以任意的放进任何多个对象。外观模式中组件的内部应该是“相互耦合关系比较大的一系列组件”,而不是一个简单的功能集合。