设计模式之桥接(bridge)模式
在现实生活中,我们常常会用到两种或多种类型的笔,比如毛笔和蜡笔。假设我们需要大、中、小三种类型的画笔来绘制12中不同的颜色,如果我们使用蜡笔,需要准备3*12=36支。但如果使用毛笔的话,只需要提供3种型号的毛笔,外加12个颜料盒即可,涉及的对象个数仅为3+12=15,远远小于36却能实现与36支蜡笔同样的功能。如果需要新增一种画笔,并且同样需要12种颜色,那么蜡笔需要增加12支,而毛笔却只需要新增1支。通过分析,在蜡笔中,颜色和型号两个不同的变化维度耦合在一起,无论对其中任何一个维度进行扩展,都势必会影响另外一个维度。但在毛笔中,颜色和型号实现了分离,增加新的颜色或者型号都对另外一方没有任何影响。在软件系统中,有些类型由于自身的逻辑,它具有两个或多个维度的变化。为了解决这种多维度变化,又不引入复杂度,这就要使用今天介绍的Bridge桥接模式。
一、跨平台的图像浏览系统
1.1 需求介绍
M公司开发部想要开发一个跨平台的图像浏览系统,要求该系统能够显示JPG、BMP、GIF、PNG等多种格式的文件,并且能够在Windows、Linux以及Unix等多个操作系统上运行。该系统首先将各种格式的文件解析为像素矩阵(Matrix),然后将像素矩阵显示在屏幕上,在不同的操作系统中可以调用不同的绘制函数来绘制像素矩阵。该系统需要具备较好的扩展性以支持新的文件格式和操作系统。
1.2 初始设计
M公司开发部的程序猿针对需求,立马提出了一个初始的设计方案,其基本结构如下图所示:
通过对这个设计方案的分析,发现存在以下两个主要问题:
(1)由于采用了多重继承结构,导致系统中类的个数急剧增加,系统中类的个数达到了17个。
(2)系统扩展麻烦,由于每一个具体类既包括图像文件格式信息,又包含操作系统信息,因此无论增加新图像文件格式还是新的操作系统,都需要增加大量的具体类。这将导致系统变得非常庞大,增加运行和维护开销。
1.3 多维度变化
通过分析可以知道,这个系统存在两个独立变化的维度:图像文件格式和操作系统,如下图所示:
如何将各种不同类型的图像文件解析为像素矩阵与图像文件格式本身相关,而如何在屏幕上绘制像素矩阵又与操作系统相关。因为初始设计中将这两种职责集中在一个类中,导致系统扩展麻烦,从类的设计角度分析,具体类BMPWindowsImage、BMPLinuxImage、BMPUnixImage等类违反了单一职责原则,因为有不止一个引起它们变化的原因,将图像文件解析和像素矩阵显示这两种完全不同的职责耦合在一起,任意一个职责发生变化都需要修改它们,因此系统扩展十分麻烦。
二、桥接模式简介
2.1 模式概述
桥接模式是一种很实用的结构型模式,如果软件系统中某个类存在两个独立变化的维度,通过该模式可以将这两个维度分离出来,使两者可以独立扩展,让系统更加符合单一职责原则。桥接模式主要使用抽象关联取代传统的多重继承,将类之间的静态继承关系转换为动态地对象组合关系,使得系统更加灵活,并易于扩展,同时有效地控制了系统中类的个数。
桥接模式的定义如下:
桥接(Bridge)模式:将抽象部分与其实现部分分离,使得他们都可以独立地变化。它是一种对象结构型模式,又称为接口模式。
2.2 类图
2.3 代码实现
图像抽象类和实例类
#pragma once #include <string> #include <iostream> using namespace std; class CAbstractPicture { public: CAbstractPicture(){} ~CAbstractPicture(){} virtual void Convert() = 0; }; class CBmp : public CAbstractPicture { public: CBmp(string strFileName):m_strFileName(strFileName) { cout << "CBmp Construct" << endl; } ~CBmp() { cout << "CBmp Deconstruct" << endl; } void Convert() { cout << "图片格式为bmp" <<endl; } private: string m_strFileName; }; class CJpg : public CAbstractPicture { public: CJpg(string strFileName):m_strFileName(strFileName) { cout << "CJpg Construct" << endl; } ~CJpg() { cout << "CJpg Deconstruct" << endl; } void Convert() { cout << "图片格式为jpg" <<endl; } private: string m_strFileName; }; class Cpng : public CAbstractPicture { public: Cpng(string strFileName):m_strFileName(strFileName) { cout << "Cpng Construct" << endl; } ~Cpng() { cout << "Cpng Deconstruct" << endl; } void Convert() { cout << "图片格式为png" <<endl; } private: string m_strFileName; };
操作系统抽象类和实例类
#pragma once #include "IntfPicture.h" class CAbstractOs { public: CAbstractOs(){} ~CAbstractOs(){} virtual void ShowPicture(CAbstractPicture *pPicture) = 0; }; class CWindows : public CAbstractOs { public: CWindows() { cout << "CWindows Construct" << endl; } ~CWindows() { cout << "CWindows Deconstruct" << endl; } void ShowPicture(CAbstractPicture *pPicture) { cout << "在windwos中显示图像"<< endl; pPicture->Convert(); } }; class CLinux : public CAbstractOs { public: CLinux() { cout << "CLinux Construct" << endl; } ~CLinux() { cout << "CLinux Deconstruct" << endl; } void ShowPicture(CAbstractPicture *pPicture) { cout << "在windwos中显示图像"<< endl; pPicture->Convert(); } };
测试代码
#include "stdio.h" #include "IntfOs.h" void main() { CAbstractOs *pOs = new CWindows(); CAbstractPicture *pPicture = new CBmp("xxx.bmp"); pOs->ShowPicture(pPicture); pPicture = new CJpg("xxx.jpg"); pOs->ShowPicture(pPicture); delete pPicture; delete pOs; return; }
三、桥接模式小结
3.1 主要优点
(1)分离抽象接口及其实现部分 -> 桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度变化
(2)取代多层继承方案 -> 极大地减少了子类的个数
(3)提高了系统可扩展性 -> 在两个变化维度中任意扩展一个维度,都不需要修改原有系统,符合开闭原则
3.2 主要缺点
(1)增加了系统的理解和设计难度 -> 需要开发者在一开始就对抽象层进行设计与编程
(2)要求正确识别出系统中两个独立变化的维度 -> 如何正确地识别需要一定的经验积累
3.3 应用场景
(1)一个类存在两个(或者多个)独立变化的维度,而且这两个(或者多个)维度都需要独立进行扩展。
(2)不希望使用继承或因为多层继承而导致系统中类的个数急剧增加。
(3)一个系统需要在抽象类和具体类之间增加更多的灵活性,避免在两个层次之间建立静态继承关系,通过桥接可以使它们在抽象层建立一个关联关系。
注:参考博客http://www.cnblogs.com/edisonchou/p/6978351.html