本篇介绍了适配器模式和外观模式及相关的面向对象设计原则。适配器模式(Adapter)和外观模式(Facade)都是用于“接口隔离”的设计模式。
- 适配器模式将一个类的接口转换成客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能在一起工作的那些类可以一起工作。
- 外观模式提供了一个统一的接口,用来访问子系统中的一群接口,外观定义了一个高层接口,让子系统更容易使用。
1 适配器模式
很多情况下,当我们已经有一个软件系统,并希望和一个新的厂商类库搭配使用,但厂商类库的接口和当前软件的接口不适配:
而我们又不想改变现有代码,于是就需要写一个适配器,来讲类库的接口转变为当前软件支持的接口:
这就是适配器模式。
适配器模式有两种实现方式,一种称为对象适配器,我们可以将被适配对象包含在适配器对象中,这样适配器就可以调用被适配对象的方法,并实现一个客户支持的接口,这种方式的类图如下:
另一种方式是类适配器,可以利用多重继承,让适配器成为被适配对象和目标接口的子类,这样就可以将被适配对象的接口转化为目标接口了,这种方式的类图如下:
显然,对象适配器通过组合来实现适配,而类适配器通过继承来实现适配,二者各有优劣,可以根据实际情况使用。
2 外观模式
外观模式非常简单,直接来看类图:
需要注意的是,外观模式并不是要把所有类的接口都整合到一起,外观对象的内部应该是一个相互关联的子系统,而不是简单的功能集合。
从客户程序的角度来看,外观模式简化了整个组件系统的接口,将他们统一起来,方便客户程序调用,这样一来子系统内部的任何变化都不会改变客户程序的调用接口,从而实现了解耦。
外观模式带来了新的设计原则:
设计原则:最少知识原则
设计中尽可能减少对象之间的交互。当然,减少对象之间的交互意味着需要更多的包装,这也可能为程序带来更高的运行开销。
外观模式更注重从架构的层次去看整个系统,而不仅仅是单个类,因此外观模式更像是一种架构设计模式。