[Java知识库]设计模式（三）结构型模式

前言

结构型设计模式，主要研究：

• 主要有哪些场景使用结构型设计模式；
• 每种场景应该使用何种设计模式；
• 以程序中的功能为核心，研究其需要几个类来实现、功能如何在类间分配，即程序功能的组织结构。所以这一章，我们要把“功能结构”作为研究的核心。

下面分别对几种结构型模式加以说明。

1. 适配器模式

先看例子：适配器模式

使用场景

想要在系统中添加某个功能，类似的功能在其他项目中已经实现，而且经过分析，旧的接口可以经过适当的封装，转换成新的适用于当前系统的接口。这样可以最大程度地复用已有的模块。

原理

通过适配器将已有功能的旧的接口，转换为新的接口，从而实现使已有的功能为新的系统服务的目的。

不适用的情况

以下情况下，不要使用适配器模式：

• 旧的接口无法转换成新的接口；
• 写适配器的工作量几乎可以重写所需的功能时。

小心使用

适配器模式其实是一种取巧的做法，在使用时需要慎重考虑。已有功能通过适配器集成到新的系统后，如果出现问题或者需要进行功能扩展，其维护成本是一个需要考虑的问题。例如，已有功能是否使用了过时的技术，或者资料不全，都可能成为项目的风险所在。

本质

适配器模式本质上是通过将一接口封装成另一种接口，实现了模块功能复用。

2. 桥接模式

例子：桥接模式

使用场景

桥接模式是少用继承，多用组合的第一例。
拿菜鸟教程中的例子来说，假如我们现在要实现圆类，包括红色圆和绿色圆两种圆。
首先容易想到的方法是，先写一个圆基类，并添加一个虚(virtual)的绘制函数。然后分别派生出红色圆类和绿色圆类，在子类中分别重新实现绘制函数，将圆绘制成指定的颜色。
在这种简单的例子中，使用继承是没什么问题的。但是假如圆基类还有一个虚函数，此虚函数用于对圆进行旋转。旋转分为两种，顺时针和逆时针旋转。我们想要四种类型的圆：

• 顺时针旋转的红色圆
• 顺时针旋转的绿色圆
• 逆时针旋转的红色圆
• 逆时针旋转的绿色圆

这个时候，我们通过如何继承来实现呢？难道要派生出四个子类吗？如果还有其他功能组合呢？要多少个类呢？这样下去无疑会导致“类的数量爆炸”问题。

原理

结构型模式是研究程序功能组织方法的设计模式。当程序中需要对几种功能相互组合时，应该用组合，不要用继承。
桥接模式下，对于每个功能，应该提取出一个接口类，这个接口类可以有不同的实现。而代表不同的功能接口，可以作为主体类（此例中为圆类）的成员变量，放在一起。需要什么功能，就new哪种接口子类，保存在接口变量中，这样就可以把不同的功能组合起来。
这样一来，类的数量会保持在最低水平。

相对于继承，桥接模式相当于把主体类中的每个虚函数都单独提取出来，构成 一个接口类。这个接口类连接了具体实现和主体类，所以这个模式叫桥接模式。这个名字其实不是很能反映此模式的内涵，其实叫“功能组合模式”更为贴切。

可能有的小伙伴会说，上面的功能其实用C语言实现不是更简单吗？

• 用一个结构体代表圆，有半径、边框宽度等属性；
• 每种功能就是一个函数，参数为圆的结构体。

这不就完成了吗？是的！
这个场景下，确实使用C语言实现更简单，不需要使用C++面向对象的任何特性即可实现。可以看出，C++的面向对象的特性，并不是万能的，并不是在所有情况下都是最优的，甚至有时候不如C语言简单直接。从另一个角度说明，大家在面向对象编程的时候，不要把自己的思维局限于面向对象，面向对象思想在一些时候，是不如面向过程的，甚至会把功能结构复杂化，设计到最后导致代码难以维护都是有可能的。

小心使用

桥接模式会导致代码中存在设计模式的代码，会增加代码的理解难度。相对来说，积极作用还是远大于副作用的。

本质

桥接模式的本质是：

如果项目中出现了功能组合的场景，使用继承封装功能是错误做法，要把功能单独提取出来分别封装好以后，再进行组合。

3. 过滤器模式