导语
接口型设计模式始终是从业务需求的角度考虑分类的,总得来说,当你拿到确定的需求时,首要考虑的是如何设计好你的输入|输出,这无论是对于系统梳理,还是程序员之间的代码交互都是有益的,即便是抽象度较高的桥接模式,在Client层,依旧是为了降低其调用和操作上的复杂度.
接口型设计模式是为了优化接口背后的实现,降低代码的维护难度,无论在结构上简单还是复杂,它们的作用和效果都是明显的.
适配器模式-Adapter
- 复杂度:低
- 适用度:非常广
- 意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
通常我们在系统设计的时候,会根据高内聚的原则,会优先定义出一些核心类(CoreClasses),这些类出现的目的并不会直接提供给Client直接使用,而是为了给系统做最底层的业务支撑.
我们当然可以直接通过这些核心类为Client提供服务,但这么做会产生两个严重的问题:一是为Client提供服务的Service类(或Client类自身)的代码非常的庞大;另一个是对于相似的功能,其内部会产生大量相似甚至一模一样的代码段.
此时我们可以使用Adapter模式优化我们的代码系统,需要强调的是如果你试图通过扩展你的核心业务类的功能来减少Client的复杂度将会与设计思想背道而驰,这样做你将会得到一批极其庞大,且与业务深度耦合的核心类.
Adapter有两个重要的特征:
- Adapter是直接面向Client原始需求的,在使用Adapter的时候,首要关注的是如何给Client提供一个直接易懂的接口
- Adapter通过继承(不建议)或持有(建议)核心类的方式,将原始需求的实现封装在Adapter自身
P.S.当然你也可以做出更多的优化,比如将Adapter的抽象与实现进行分离,以确保其在开闭原则下,必要的功能得到了实现,但这些都是扩充的部分.
外观模式-Facade
- 复杂度:低
- 适用度:广
- 意图：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
外观模式是一个系统与子系统关系层面的设计概念,侧重点在于统一了操作对象,对于Client而言,使用Facade模式意味着Client不必关注业务功能具体需要调用哪个类,想要实现Client期望的功能,只需要始终面对一个类的对象即可.
Facade模式具有一些特征:
- Facade通常会持有若干个子系统的类(ChildSystems),这些子系统的类所提供的功能是完善独立的.
- 相较于Adapter的封装,Facade一般不会持有核心业务类(CoreClasses),也不会在其提供的方法中作过多的业务逻辑实现.
组合模式-Composite
- 复杂度:较高
- 适用度:一般
- 意图：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
组合(合成)模式所适用的场景十分的明显,当你发现接下来的程序设计中满足下面两个特点,就可以首先考虑Composite模式了:
- 需要设计的对象存在对自身递归调用的要求时,这种特征经常出现在算法设计,数据挖掘这样的业务类型中
- 在递归调用特征的前提下,需要对外部暴露统一操作接口时,例如文件系统中"文件夹-文件"的操作
P.S.Composite模式从结构上看,是有可能出现"环"结构的,这种情况需要根据具体的业务要求做处理,但其目的都是为了保证递归行为能够遍历到所有节点且不会形成死循环.
桥接模式-Bridge
- 复杂度:一般
- 适用度:广
- 意图：将抽象部分与实现部分分离，使它们都可以独立的变化。
Bridge是抽象编程的范例,所谓抽象部分与实现县部分分离,具体的讲,桥接模式至少涉及两个抽象类:
- 组件的抽象类(abstract components),这个抽象类(也可以是接口)用来声明需要执行的操作,而具体的实现需要在其子类(实现类)编写.
- 柄体(handle body),这个抽象类会持有抽象组件(abstract components)的引用,同时在柄体中定义必要的操作(抽象类允许编写方法的实现)
在这个过程中,开发人员编码的类都是抽象的,包括柄体中的代码块,这就是其中抽象分离的部分,实现分离指的是组件抽象类(abstrace components)的子类(实现类),你可以编写多个子类,然后在Client中通过对柄体的子类(你完全可以将柄体设计成普通的类,这里之所以设计成抽象类是因为多数情况下,柄体也需要声明一些抽象行为,而这些行为需要在其子类中实现,但严格的讲将柄体设计成抽象类并非是bridge的核心)的操作,将组件抽象类(abstract components)的子类作为引用传入柄体的子类,最终达到调用了不同实现的目的.
P.S.深入理解Bridge模式的设计原则是重要的,因为这是针对抽象变成的重要范例,很多设计模式都会基于"抽象&实现分离"的思想做设计.基于这种设计理念(不限于Bridge),你可以更多的关注你的设计是否合理,避免实现部分对系统架构的干扰.
结语
设计模式本身的区别并没有那么明显,例如策略模式和状态模式这种,另外在系统设计的过程中,"模式"通常是混合出现的,所以才会有人提出了一些设计原则和设计思想,目的是为了打破工程师对设计模式的定式思维.当然,至少你要对Base的部分有相对充分的理解才行.
附录
本文由 momoker 创作，采用 知识共享署名4.0
国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Mar 18,2022