设计模式之：桥接模式

目录

• 桥接模式概述
• 桥接模式的结构与实现
• 桥接模式的应用实例
• 桥接模式与适配器模式的联用
• 桥接模式的优缺点与适用环境

桥接模式概述

毛笔与蜡笔的故事

• 蜡笔：颜色和型号两个不同的变化维度（即两个不同的变化原因）耦合在一起，无论是对颜色进行扩展还是对型号进行扩展都势必会影响另一个维度
• 毛笔：颜色和型号实现了分离，增加新的颜色或者型号对另一方没有任何影响

分析：

画笔中存在的两个独立变化维度示意图。在软件开发过程中如何将多个变化维度分离？

桥接模式

桥接模式的定义：桥接模式：将抽象部分与它的实现部分解耦，使得两者都能够独立变化。Bridge Pattern: Decouple an abstraction from its implementation so that the two can vary independently.

• 又被称为柄体(Handle and Body)模式或接口(Interface)模式
• 用抽象关联取代了传统的多层继承
• 将类之间的静态继承关系转换为动态的对象组合关系

桥接模式的结构与实现

桥接模式的结构：

桥接模式包含以下4个角色：

• Abstraction（抽象类）

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

• RefinedAbstraction（扩充抽象类）

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

• Implementor（实现类接口）

定义实现类的接口，这个接口不一定要与Abstraction的接口完全一致，事实上这两个接口可以完全不同，一般来讲，Implementor接口仅提供基本操作，而Abstraction定义的接口可能会做更多复杂的操作。Implementor接口对这些基本操作进行了定义，而具体实现交给其子类。通过关联关系，在Abstraction中不仅拥有自己的方法，还可以调用Implementor中定义的方法，使用关联关系来替代继承关系。

• ConcreteImplementor（具体实现类）

实现Implementor接口并且具体实现它，在不同的ConcreteImplementor中提供基本操作的不同实现，在程序运行时，ConcreteImplementor对象将替换其父类对象，提供给客户端具体的业务操作方法。

桥接模式的实现：

典型的实现类接口代码：

public interface Implementor {
	public void operationImpl();
}

典型的具体实现类代码：

public class ConcreteImplementor implements Implementor {
	@Override
	public void operationImpl() {
		// 具体业务方法的实现
	}
}

典型的抽象类代码：

public abstract class Abstraction {
	protected Implementor impl;

	public void setImpl(Implementor impl) {
		this.impl = impl;
	}

	public abstract void operation();
}

典型的扩充抽象类（细化抽象类）代码：

public class RefinedAbstraction extends Abstraction {
	@Override
	public void operation() {
		// 代码
		impl.operationImpl();
		// 代码
	}
}

桥接模式的应用实例

某软件公司要开发一个跨平台图像浏览系统，要求该系统能够显示BMP、JPG、GIF、PNG等多种格式的文件，并且能够在Windows、Linux、UNIX等多个操作系统上运行。系统首先将各种格式的文件解析为像素矩阵(Matrix)，然后将像素矩阵显示在屏幕上，在不同的操作系统中可以调用不同的绘制函数来绘制像素矩阵。另外，系统需具有较好的扩展性，以便在将来支持新的文件格式和操作系统。试使用桥接模式设计该跨平台图像浏览系统。

实例类图：

实例代码：

• (1) Matrix：像素矩阵类，辅助类
• (2) ImageImp：抽象操作系统实现类，充当实现类接口
• (3) WindowsImp：Windows操作系统实现类，充当具体实现类
• (4) LinuxImp：Linux操作系统实现类，充当具体实现类
• (5) UnixImp：UNIX操作系统实现类，充当具体实现类
• (6) Image：抽象图像类，充当抽象类
• (7) JPGImage：JPG格式图像类，充当扩充抽象类
• (8) PNGImage：PNG格式图像类，充当扩充抽象类
• (9) BMPImage：BMP格式图像类，充当扩充抽象类
• (10) GIFImage：GIF格式图像类，充当扩充抽象类
• (11) 配置文件App.config
• (12) Program：客户端测试类

结果及分析：

如果需要更换图像文件格式或者更换操作系统，只需修改配置文件即可

桥接模式与适配器模式的联用

桥接模式：用于系统的初步设计，对于存在两个独立变化维度的类可以将其分为抽象化和实现化两个角色，使它们可以分别进行变化

适配器模式：当发现系统与已有类无法协同工作时

 

桥接模式的优缺点与适用环境

模式优点

• 分离抽象接口及其实现部分
• 可以取代多层继承方案，极大地减少了子类的个数
• 提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，不需要修改原有系统，符合开闭原则

模式缺点

• 会增加系统的理解与设计难度，由于关联关系建立在抽象层，要求开发者一开始就针对抽象层进行设计与编程
• 正确识别出系统中两个独立变化的维度并不是一件容易的事情

模式适用环境

• 需要在抽象化和具体化之间增加更多的灵活性，避免在两个层次之间建立静态的继承关系
• 抽象部分和实现部分可以以继承的方式独立扩展而互不影响
• 一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立地进行扩展
• 不希望使用继承或因为多层继承导致系统类的个数急剧增加的系统

思考问题：

如果系统中存在两个以上的变化维度，是否可以使用桥接模式进行处理？如果可以，系统该如何设计？