Facade
“接口隔离”模式
在组件构建过程中,某些接口之间直接的依赖常常会带来很多问题,甚至根本无法实现。采用添加一层间接(稳定)接口,来隔离本来相互紧密关联的接口是一种常见的解决方案。
典型模型
Facade(门面模式)
Proxy(代理模式)
Adapter(适配器)
Mediator(中介者)
动机(Motivation)
A方案,子系统中的各个部分和客户系统之间很多紧耦合,不太合适,加一个间接层,客户系统仅仅和Facade系统(间接层)打交道
上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战。
如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦?
《设计模式》GOF的定义:
为子系统中的一组接口提供一个一致(稳定)的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用(复用)。
Facade并没有一种固定的代码,核心在于将所有的变化隔离,之后建立一个间接层Facade,客户和Facade直接进行交互,从而隔离了变化。
要点总结
从客户程序的角度来看,Facade模式简化了整个组件系统的接口,对于组件内部与外部客户程序来说,达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facade很多时候更是一种架构设计模式。
Facade设计模式并非一个集装箱,可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”,而不是一个简单的功能集合。