征途游戏中的桥接模式—设计模式深度解析

在软件设计中，桥接模式是一种结构型设计模式，用于将一个类中的两个独立变化的维度分离，使它们可以独立扩展，从而提高系统的灵活性和可维护性。本文通过毛笔和蜡笔的类比，详细介绍了桥接模式的应用及其在跨平台图像浏览系统中的重构案例。通过使用桥接模式，可以有效减少系统中类的数量，简化扩展过程，并遵循单一职责原则，提升系统的可扩展性和灵活性。

在现实生活中，我们常常会用到两种或多种类型的笔，比如毛笔和蜡笔。假设我们需要大、中、小三种类型的画笔来绘制12中不同的颜色，如果我们使用蜡笔，需要准备3*12=36支。但如果使用毛笔的话，只需要提供3种型号的毛笔，外加12个颜料盒即可，涉及的对象个数仅为3+12=15，远远小于36却能实现与36支蜡笔同样的功能。如果需要新增一种画笔，并且同样需要12种颜色，那么蜡笔需要增加12支，而毛笔却只需要新增1支。通过分析，在蜡笔中，颜色和型号两个不同的变化维度耦合在一起，无论对其中任何一个维度进行扩展，都势必会影响另外一个维度。但在毛笔中，颜色和型号实现了分离，增加新的颜色或者型号都对另外一方没有任何影响。在软件系统中，有些类型由于自身的逻辑，它具有两个或多个维度的变化。为了解决这种多维度变化，又不引入复杂度，这就要使用今天介绍的Bridge桥接模式。

桥接模式（Bridge）

学习难度：★★★☆☆

使用频率：★★★☆☆

M公司开发部的程序猿针对需求，立马提出了一个初始的设计方案，其基本结构如下图所示：

通过对这个设计方案的分析，发现存在以下两个主要问题：

（1）由于采用了多重继承结构，导致系统中类的个数急剧增加，系统中类的个数达到了17个。

（2）系统扩展麻烦，由于每一个具体类既包括图像文件格式信息，又包含操作系统信息，因此无论增加新图像文件格式还是新的操作系统，都需要增加大量的具体类。这将导致系统变得非常庞大，增加运行和维护开销。

通过分析可以知道，这个系统存在两个独立变化的维度：图像文件格式和操作系统，如下图所示：

如何将各种不同类型的图像文件解析为像素矩阵与图像文件格式本身相关，而如何在屏幕上绘制像素矩阵又与操作系统相关。因为初始设计中将这两种职责集中在一个类中，导致系统扩展麻烦，从类的设计角度分析，具体类BMPWindowsImage、BMPLinuxImage、BMPUnixImage等类违反了单一职责原则，因为有不止一个引起它们变化的原因，将图像文件解析和像素矩阵显示这两种完全不同的职责耦合在一起，任意一个职责发生变化都需要修改它们，因此系统扩展十分麻烦。

桥接模式是一种很实用的结构型模式，如果软件系统中某个类存在两个独立变化的维度，通过该模式可以将这两个维度分离出来，使两者可以独立扩展，让系统更加符合单一职责原则。桥接模式主要使用抽象关联取代传统的多重继承，将类之间的静态继承关系转换为动态地对象组合关系，使得系统更加灵活，并易于扩展，同时有效地控制了系统中类的个数。

桥接模式的定义如下：

桥接模式的结构与其名称一样，存在一条连接两个继承等级结构的桥，桥接模式结果如下所示：

（1）Abstraction（抽象类）：用于定义抽象类的接口，其中定义了一个实现了Implementor接口的对象并可以维护该对象，它与Implementor之间具有关联关系，它既可以包含抽象业务方法， 也可以包含具体业务方法。

（2）RefinedAbstratction（扩充抽象类）：扩充由Abstraction定义的接口，通常情况下他不再是抽象类而是具体类，实现了在Abstraction中声明的抽象业务方法，在RefinedAbstraction中可以调用在Implementor中定义的业务方法。

（3）Implementor（实现类接口）：定义实现类的接口，一般而言，它不与Abstraction的接口一致。它只提供基本操作，而Abstraction定义的接口可能会做更多更复杂的操作。

（4）ConcreteImplementor（具体实现类）：具体实现Implementor接口，在不同的ConcreteImplementor中提供基本操作的不同实现，在程序运行时，ConcreteImplentor将替换其父类对象，提供给抽象类具体的业务操作方法。

要使用桥接模式，首先应该识别出一个类所具有的两个独立变化的维度，将他们设计成两个独立的继承等级结构，为两个维度都提供抽象层，并建立抽象耦合。

这里我们看一个例子，最开始我们提到毛笔，对于它而言，型号是其固有的维度，因此可以设计一个抽象的毛壁垒，在该类中声明并部分实现毛笔的业务方法，而将各种型号的毛笔作为其子类；颜色是毛笔的另一个维度，由于它与毛笔之间存在一种“设置”的关系，因此可以提供一个抽象的颜色接口，而将具体的颜色作为实现该接口的子类。在此，型号可以认为是毛笔的抽象部分，而颜色是毛笔的实现部分，其结构示意图如下：

为了减少所需生成的子类数目，实现将操作系统和图像文件格式两个维度的分离，使他们可以独立改变，M公司开发人员决定使用桥接模式来重构设计方案，其基本示意图如下所示：

（0）辅助类

    public class AppConfigHelper    {        public static string GetImageFormatName()        {            string factoryName = null;            try            {                factoryName = System.Configuration.ConfigurationManager.AppSettings["RefinedAbstraction"];            }            catch (Exception ex)            {                Console.WriteLine(ex.Message);            }            return factoryName;        }        public static object GetImageInstance()        {            string assemblyName = AppConfigHelper.GetImageFormatName();            Type type = Type.GetType(assemblyName);            var instance = Activator.CreateInstance(type);            return instance;        }        public static string GetEnvName()        {            string factoryName = null;            try            {                factoryName = System.Configuration.ConfigurationManager.AppSettings["ConcreteImplementor"];            }            catch (Exception ex)            {                Console.WriteLine(ex.Message);            }            return factoryName;        }        public static object GetEnvInstance()        {            string assemblyName = AppConfigHelper.GetEnvName();            Type type = Type.GetType(assemblyName);            var instance = Activator.CreateInstance(type);            return instance;        }    }

编译后运行，输出结果如下：

由于配置文件设置的操作系统是Linux，图片格式是JPG，所以输出上图。

这时，如果我们将配置文件改为Windows和GIF，会输出下图所示：

（1）分离抽象接口及其实现部分 -> 桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度变化

（2）取代多层继承方案 -> 极大地减少了子类的个数

（3）提高了系统可扩展性 -> 在两个变化维度中任意扩展一个维度，都不需要修改原有系统，符合开闭原则

（1）增加了系统的理解和设计难度 -> 需要开发者在一开始就对抽象层进行设计与编程

（2）要求正确识别出系统中两个独立变化的维度 -> 如何正确地识别需要一定的经验积累

（1）一个类存在两个（或者多个）独立变化的维度，而且这两个（或者多个）维度都需要独立进行扩展。

（2）不希望使用继承或因为多层继承而导致系统中类的个数急剧增加。

（3）一个系统需要在抽象类和具体类之间增加更多的灵活性，避免在两个层次之间建立静态继承关系，通过桥接可以使它们在抽象层建立一个关联关系。

刘伟，《设计模式的艺术—软件开发人员内功修炼之道》

作者：周旭龙

出处：http://edisonchou.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。

今天关于《征途游戏中的桥接模式—设计模式深度解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！