.NET设计模式(9):桥接模式(Bridge Pattern)(转)
概述
在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式。
意图
将抽象部分与实现部分分离,使它们都可以独立的变化。[GOF 《设计模式》]
结构图
图1 Bridge模式结构图
生活中的例子
桥接模式将抽象部分与它的实现分离,使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等,都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关,也可以是调光开关。
图2 使用电子开关例子的桥接对象图
桥接模式解说
在创建型模式里面,我曾经提到过抽象与实现,抽象不应该依赖于具体实现细节,实现细节应该依赖于抽象。看下面这幅图:
图3 抽象不应该依赖于实现细节
在这种情况下,如果抽象B稳定,而实现细节b变化,这时用创建型模式来解决没有问题。但是如果抽象B也不稳定,也是变化的,该如何解决?这就要用到Bridge模式了。
我们仍然用日志记录工具这个例子来说明Bridge模式。现在我们要开发一个通用的日志记录工具,它支持数据库记录DatabaseLog和文本文件记录FileLog两种方式,同时它既可以运行在.NET平台,也可以运行在Java平台上。
根据我们的设计经验,应该把不同的日志记录方式分别作为单独的对象来对待,并为日志记录类抽象出一个基类Log出来,各种不同的日志记录方式都继承于该基类:
图4 Log类结构图
实现代码如下:
public abstract class Log
{
public abstract void Write(string log);
}
public class DatabaseLog : Log
{
public override void Write(string log)
{
//......Log Database
}
}
public class TextFileLog : Log
{
public override void Write(string log)
{
//......Log Text File
}
}
另外考虑到不同平台的日志记录,对于操作数据库、写入文本文件所调用的方式可能是不一样的,为此对于不同的日志记录方式,我们需要提供各种不同平台上的实现,对上面的类做进一步的设计得到了下面的结构图:
图5
实现代码如下:
public class NDatabaseLog : DatabaseLog
{
public override void Write(string log)
{
//......(.NET平台)Log Database
}
}
public class JDatabaseLog : DatabaseLog
{
public override void Write(string log)
{
//......(Java平台)Log Database
}
}
public class NTextFileLog : TextFileLog
{
public override void Write(string log)
{
//......(.NET平台)Log Text File
}
}
public class JTextFileLog : TextFileLog
{
public override void Write(string log)
{
//......(Java平台)Log TextFile
}
}
现在的这种设计方案本身是没有任何错误的,假如现在我们要引入一种新的xml文件的记录方式,则上面的类结构图会变成:
图6
如图中蓝色的部分所示,我们新增加了一个继承于Log基类的子类,而没有修改其它的子类,这样也符合了开放-封闭原则。如果我们引入一种新的平台,比如说我们现在开发的日志记录工具还需要支持Borland平台,此时该类结构又变成了:
图7
同样我们没有修改任何的东西,只是增加了两个继承于DatabaseLog和TextFileLog的子类,这也符合了开放-封闭原则。
但是我们说这样的设计是脆弱的,仔细分析就可以发现,它还是存在很多问题,首先它在遵循开放-封闭原则的同时,违背了类的单一职责原则,即一个类只有一个引起它变化的原因,而这里引起Log类变化的原因却有两个,即日志记录方式的变化和日志记录平台的变化;其次是重复代码会很多,不同的日志记录方式在不同的平台上也会有一部分的代码是相同的;再次是类的结构过于复杂,继承关系太多,难于维护,最后最致命的一点是扩展性太差。上面我们分析的变化只是沿着某一个方向,如果变化沿着日志记录方式和不同的运行平台两个方向变化,我们会看到这个类的结构会迅速的变庞大。
现在该是Bridge模式粉墨登场的时候了,我们需要解耦这两个方向的变化,把它们之间的强耦合关系改成弱联系。我们把日志记录方式和不同平台上的实现分别当作两个独立的部分来对待,对于日志记录方式,类结构图仍然是:
图8
现在我们引入另外一个抽象类ImpLog,它是日志记录在不同平台的实现的基类,结构图如下:
图9
实现代码如下:
public abstract class ImpLog
{
public abstract void Execute(string msg);
}
public class NImpLog : ImpLog
{
public override void Execute(string msg)
{
//...... .NET平台
}
}
public class JImpLog : ImpLog
{
public override void Execute(string msg)
{
//...... Java平台
}
}
这时对于日志记录方式和不同的运行平台这两个类都可以独立的变化了,我们要做的工作就是把这两部分之间连接起来。那如何连接呢?在这里,Bridge使用了对象组合的方式,类结构图如下:
图 10
实现代码如下:
public abstract class Log
{
protected ImpLog implementor;
public ImpLog Implementor
{
set { implementor = value; }
}
public virtual void Write(string log)
{
implementor.Execute(log);
}
}
public class DatabaseLog : Log
{
public override void Write(string log)
{
implementor.Execute(log);
}
}
public class TextFileLog : Log
{
public override void Write(string log)
{
implementor.Execute(log);
}
}
可以看到,通过对象组合的方式,Bridge模式把两个角色之间的继承关系改为了耦合的关系,从而使这两者可以从容自若的各自独立的变化,这也是Bridge模式的本意。再来看一下客户端如何去使用:
class App
{
public static void Main(string[] args)
{
//.NET平台下的Database Log
Log dblog = new DatabaseLog();
dblog.Implementor = new NImpLog();
dblog.Write();
//Java平台下的Text File Log
Log txtlog = new TextFileLog();
txtlog.Implementor = new JImpLog();
txtlog.Write();
}
}
可能有人会担心说,这样不就又增加了客户程序与具体日志记录方式之间的耦合性了吗?其实这样的担心是没有必要的,因为这种耦合性是由于对象的创建所带来的,完全可以用创建型模式去解决,就不是这里我们所讨论的内容了。
最后我们再来考虑一个问题,为什么Bridge模式要使用对象组合的方式而不是用继承呢?如果采用继承的方式,则Log类,ImpLog类都为接口,类结构图如下:
图11
实现代码如下:
public class NDatabaseLog : DatabaseLog, IImpLog
{
//......
}
public class JDatabaseLog : DatabaseLog, IImpLog
{
//......
}
public class NTextFileLog : TextFileLog, IImpLog
{
//......
}
public class JTextFileLog : TextFileLog, IImpLog
{
//......
}
如上图中蓝色的部分所示,它们既具有日志记录方式的特性,也具有接口IimpLog的特性,它已经违背了面向对象设计原则中类的单一职责原则,一个类应当仅有一个引起它变化的原因。所以采用Bridge模式往往是比采用多继承更好的方案。说到这里,大家应该对Bridge模式有一些认识了吧?如果在开发中遇到有两个方向上纵横交错的变化时,应该能够想到使用Bridge模式,当然了,有时候虽然有两个方向上的变化,但是在某一个方向上的变化并不是很剧烈的时候,并不一定要使用Bridge模式。
效果及实现要点
1.Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。
2.所谓抽象和实现沿着各自维度的变化,即“子类化”它们,得到各个子类之后,便可以任意它们,从而获得不同平台上的不同型号。
3.Bridge模式有时候类似于多继承方案,但是多继承方案往往违背了类的单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4.Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。
适用性
在以下的情况下应当使用桥梁模式:
1.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的联系。
2.设计要求实现化角色的任何改变不应当影响客户端,或者说实现化角色的改变对客户端是完全透明的。
3.一个构件有多于一个的抽象化角色和实现化角色,系统需要它们之间进行动态耦合。
4.虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。
总结
Bridge模式是一个非常有用的模式,也非常复杂,它很好的符合了开放-封闭原则和优先使用对象,而不是继承这两个面向对象原则。
参考资料
阎宏,《Java与模式》,电子工业出版社
James W. Cooper,《C#设计模式》,电子工业出版社
Alan Shalloway James R. Trott,《Design Patterns Explained》,中国电力出版社
MSDN WebCast 《C#面向对象设计模式纵横谈(8):Bridge桥接模式(结构型模式)》
.NET设计模式(9):桥接模式(Bridge Pattern)(转)的更多相关文章
- 乐在其中设计模式(C#) - 桥接模式(Bridge Pattern)
原文:乐在其中设计模式(C#) - 桥接模式(Bridge Pattern) [索引页][源码下载] 乐在其中设计模式(C#) - 桥接模式(Bridge Pattern) 作者:webabcd 介绍 ...
- 【设计模式】桥接模式 Bridge Pattern
开篇还是引用吕振宇老师的那篇经典的文章<设计模式随笔-蜡笔与毛笔的故事>.这个真是太经典了,没有比这个例子能更好的阐明桥接模式了,这里我就直接盗来用了. 现在市面上卖的蜡笔很多,各种型号, ...
- python 设计模式之桥接模式 Bridge Pattern
#写在前面 前面写了那么设计模式了,有没有觉得有些模式之间很类似,甚至感觉作用重叠了,模式并不是完全隔离和独立的,有的模式内部其实用到了其他模式的技术,但是又有自己的创新点,如果一味地认为每个模式都是 ...
- 二十四种设计模式:桥接模式(Bridge Pattern)
桥接模式(Bridge Pattern) 介绍将抽象部分与它的实现部分分离,使它们都可以独立地变化. 示例有一个Message实体类,对它的操作有Insert()和Get()方法,现在使这些操作的抽象 ...
- 桥接模式(Bridge Pattern)
1,定义 桥接模式(Bridge Pattern),也称为桥梁模式,其用意是将抽象化与实现化脱耦,使得两者可以独立的变化,它可以使软件系统沿着多个方向进行变化,而又不引入额外的复杂 ...
- Net设计模式实例之桥接模式( Bridge Pattern)
一.桥接模式简介(Brief Introduction) 桥接模式(Bridge Pattern),将抽象部分与它的实现部分分离,使的抽象和实现都可以独立地变化. Decouple an abstra ...
- 转:设计模式-----桥接模式(Bridge Pattern)
转自:http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html 记得看原始链接的评论. 学习设计模式也有一段时间了,今天就把我整理 ...
- C#设计模式——桥接模式(Bridge Pattern)
一.概述在软件开发中,我们有时候会遇上一个对象具有多个变化维度.比如对汽车对象来说,可能存在不同的汽车类型,如公共汽车.轿车等,也可能存在不同的发动机,如汽油发动机.柴油发动机等.对这类对象,可应用桥 ...
- [设计模式] 7 桥接模式 bridge
#include<iostream> using namespace std; class AbstractionImp { public: virtual ~AbstractionImp ...
- 七个结构模式之桥接模式(Bridge Pattern)
问题: 当存在多个独立的变化维度时,如果仍采用多层继承结构,会急剧的增加类的个数,因此可以考虑将各个维度分类,使他们不相互影响. 定义: 将抽象部分与它的实现部分进行分离,抽象部分只保留最为本质的部分 ...
随机推荐
- Mayan游戏 (codevs 1136)题解
[问题描述] Mayan puzzle是最近流行起来的一个游戏.游戏界面是一个7行5列的棋盘,上面堆放着一些方块,方块不能悬空堆放,即方块必须放在最下面一行,或者放在其他方块之上.游戏通关是指在规定的 ...
- JavaWeb之 Servlet执行过程 与 生命周期
Servlet的概念 什么是Servlet呢? Java中有一个叫Servlet的接口,如果一个普通的类实现了这个接口,这个类就是一个Servlet.Servlet下有一个实现类叫HttpServle ...
- 刀哥多线程同步任务作用gcd-07-sync_task
同步任务的作用 同步任务,可以让其他异步执行的任务,依赖某一个同步任务 例如:在用户登录之后,再异步下载文件! - (void)gcdDemo1 { dispatch_queue_t queue = ...
- shell字符串的截取
1.变量 var 从 npos ∈ [0, length-1] 位开始,从左->右截取 num 个字符: ${var:npos:num} / ${var:npos} 小结:若 npos < ...
- C# WinForm自定义控件响应键盘事件
自己定义的winform控件,用其他键盘事件都无法响应,只有用ProcessCmdKey事件可以达到目的(别忘了主窗体的KeyPreview属性要设置为true),写法如下: prot ...
- Linux软链接与硬链接
1.Linux链接概念Linux链接分两种,一种被称为硬链接(Hard Link),另一种被称为符号链接(Symbolic Link).默认情况下,ln命令产生硬链接. [硬连接]硬连接指通过索引节点 ...
- linux kernel 0.11 head
head的作用 注意:bootsect和setup汇编采用intel的汇编风格,而在head中,此时已经进入32位保护模式,汇编的采用的AT&T的汇编语言,编译器当然也就变成对应的编译和连接器 ...
- zip解压缩
package com.green.project.compress; import java.io.File;import java.io.FileInputStream;import java.i ...
- 嵌入式web服务
:boa.thttpd.mini_httpd.shttpd.lighttpd.goaheand.appweb和apache等. Boa 1.介绍 Boa诞生于1991年,作者Paul Philips. ...
- wpa_supplicant软件架构分析
wpa_supplicant软件架构分析 1. 启动命令 wpa supplicant 在启动时,启动命令可以带有很多参数,目前我们的启动命令如下: wpa_supplicant /system/bi ...