10-桥接模式

133 阅读4分钟
欢迎关注千羽的公众号

程序员千羽

Github:github.com/nateshao/de…

1. 桥接模式概述

定义

桥接模式:将抽象部分与它的实现部分解耦,使得两者都能够独立变化。

对象结构型模式

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

桥接模式的结构

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

  1. Abstraction(抽象类)
  2. RefinedAbstraction(扩充抽象类)
  3. Implementor(实现类接口)
  4. ConcreteImplementor(具体实现类)

2. 桥接模式的结构与实现

典型的实现类接口代码:

public interface Implementor {
    public void operationImpl();
}

典型的具体实现类代码:

public class ConcreteImplementor implements Implementor {
    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 {
    public void operation() {
        //业务代码
        impl.operationImpl(); //调用实现类的方法
        //业务代码
    }
}

3. 桥接模式的应用实例

实例说明:某软件公司要开发一个跨平台图像浏览系统,要求该系统能够显示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. Client:客户端测试类

结果及分析:如果需要更换图像文件格式或者更换操作系统,只需修改配置文件即可

<?xml version="1.0"?>
<config>
    <!--RefinedAbstraction-->
    <className>designpatterns.bridge.JPGImage</className> 
    <!--ConcreteImplementor-->
    <className>designpatterns.bridge.WindowsImp</className>
</config>

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

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

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

桥接模式与适配器模式联用示意图

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

模式优点

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

模式缺点

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

模式适用环境

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