桥接模式(Bridge Pattern)

设计模式 - 吕震宇

.NET设计模式系列文章

薛敬明的专栏

乐在其中设计模式(C#)

设计模式（16）－Bridge Pattern

一、 桥梁（Bridge）模式

桥梁模式是一个非常有用的模式，也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则，包括"开－闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。

注：《Java与模式》一书认为Bridge模式不是一个使用频率很高的模式，我不太赞同，我认为Bridge模式中蕴涵了很多设计模式的关键思想在里面，所以我这里采纳了《Design Patterns Explained》一书的作者Alan Shalloway与James R. Trott的观点：The Bridge pattern is quite a bit more complex than the other patterns you just
learned; it is also much more useful.

桥梁模式的用意

【GOF95】在提出桥梁模式的时候指出，桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。

抽象化

存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待【LISKOV94】。

实现化

抽象化给出的具体实现，就是实现化。

脱耦

所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。

二、 桥梁模式的结构

桥梁模式【GOF95】是对象的结构模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

下图所示就是一个实现了桥梁模式的示意性系统的结构图。



可以看出，这个系统含有两个等级结构，也就是：

由抽象化角色和修正抽象化角色组成的抽象化等级结构。
由实现化角色和两个具体实现化角色所组成的实现化等级结构。

桥梁模式所涉及的角色有：

抽象化(Abstraction)角色：抽象化给出的定义，并保存一个对实现化对象的引用。
修正抽象化(Refined Abstraction)角色：扩展抽象化角色，改变和修正父类对抽象化的定义。
实现化(Implementor)角色：这个角色给出实现化角色的接口，但不给出具体的实现。必须指出的是，这个接口不一定和抽象化角色的接口定义相同，实际上，这两个接口可以非常不一样。实现化角色应当只给出底层操作，而抽象化角色应当只给出基于底层操作的更高一层的操作。
具体实现化(Concrete Implementor)角色：这个角色给出实现化角色接口的具体实现。

三、 桥梁模式的示意性源代码

// Bridge pattern -- Structural example


using System;




// "Abstraction"


class Abstraction


{


// Fields


protected Implementor implementor;




// Properties


public Implementor Implementor


{


set{ implementor = value; }


}




// Methods


virtual public void Operation()


{


implementor.Operation();


}


}




// "Implementor"


abstract class Implementor


{


// Methods


abstract public void Operation();


}




// "RefinedAbstraction"


class RefinedAbstraction : Abstraction


{


// Methods


override public void Operation()


{


implementor.Operation();


}


}




// "ConcreteImplementorA"


class ConcreteImplementorA : Implementor


{


// Methods


override public void Operation()


{


Console.WriteLine("ConcreteImplementorA Operation");


}


}




// "ConcreteImplementorB"


class ConcreteImplementorB : Implementor


{


// Methods


override public void Operation()


{


Console.WriteLine("ConcreteImplementorB Operation");


}


}




/// <summary>


/// Client test


/// </summary>


public class Client


{


public static void Main( string[] args )


{


Abstraction abstraction = new RefinedAbstraction();




// Set implementation and call


abstraction.Implementor = new ConcreteImplementorA();


abstraction.Operation();




// Change implemention and call


abstraction.Implementor = new ConcreteImplementorB();


abstraction.Operation();


}


}

四、 调制解调器问题

感觉《敏捷软件开发－原则、模式与实践》中关于Bridge模式的例子很好。（《Java与模式》一书33章的对变化的封装一节也写得很不错，推荐大家读一读。它深入的阐述了《Design Patterns Explained》一书中"1）Design to interfaces. 2)Favor composition over inheritance. 3)Find what varies and encapsulate it"的三个观点。）。



如图所示，有大量的调制解调器客户程序在使用Modem接口。Modem接口被几个派生类HayesModem、USRoboticsModem和EarniesModem实现。它很好地遵循了OCP、LSP和DIP。当增加新种类的调制解调器时，调制解调器的客户程序不会受影响。

假定这种情形持续了几年，并有许多调制解调器的客户程序都在使用着Modem接口。现出现了一种不拨号的调制解调器，被称为专用调制解调器。它们位于一条专用连接的两端。有几个新应用程序使用这些专用调制解调器，它们无需拨号。我们称这些使用者为DedUser。但是，客户希望当前所有的调制解调器客户程序都可以使用这些专用调制解调器。他们不希望去更改许许多多的调制解调器客户应用程序，所以完全可以让这些调制解调器客户程序去拨一些假(dummy)电话号码。

如果能选择的话，我们会把系统的设计更改为下图所示的那样。



我们把拨号和通信功能分离为两个不同的接口。原来的调制解调器实现这两个接口，而调制解调器客户程序使用这两个接口。DedUser只使用Modem接口，而DedicateModem只实现Modem接口。但这样做会要求我们更改所有的调制解调器客户程序--这是客户不允许的。

一个可能的解决方案是让DedicatedModem从Modem派生并且把dial方法和hangup方法实现为空，就像下面这样：



几个月后，已经有了大量的DedUser，此时客户提出了一个新的更改。为了能拨国际电话号码、信用卡电话、PIN标识电话等等，必修对现有dial中使用char[10]存储号码改为能够拨打任意长度的电话号码。

显然，所有的调制解调器客户程序都必须更改。客户同意了对调制解调器客户程序的更改，因为他们别无选择。糟糕的是，现在必须要去告诉DedUser的编写者，他们必须要更改他们的代码！你可以想象他们听到这个会有多高兴。本来他们是不用调用dial的。

这就是许多项目都会具有的那种有害的混乱依赖关系。系统某一部分中的一个杂凑体(kludge)创建了一个有害的依赖关系，最终导致系统中完全无关的部分出现问题。

如果使用ADAPTER模式解决最初的问题的话，就可以避免这个严重问题。如图：



请注意，杂凑体仍然存在。适配器仍然要模拟连接状态。然而，所有的依赖关系都是从适配器发起的。杂凑体和系统隔离，藏身于几乎无人知晓的适配器中。

BRIDGE模式

看待这个问题，还有另外一个方式。现在，出现了另外一种切分Modem层次结构的方式。如下图：



这不是一个理想的结构。每当增加一款新硬件时，就必须创建两个新类--一个针对专用的情况，一个针对拨号的情况。每当增加一种新连接类型时，就必须创建3个新类，分别对应3款不同的硬件。如果这两个自由度根本就是不稳定的，那么不用多久，就会出现大量的派生类。

在类型层次结构具有多个自由度的情况中，BRIDGE模式通常是有用的。我们可以把这些层次结构分开并通过桥把它们结合到一起，而不是把它们合并起来。如图：



我们把调制解调器类层次结构分成两个层次结构。一个表示连接方法，另一个表示硬件。

这个结构虽然复杂，但是很有趣。它的创建不会影响到调制解调器的使用者，并且还完全分离了连接策略和硬件实现。ModemConnectController的每个派生类代表了一个新的连接策略。在这个策略的实现中可以使用sendlmp、receivelmp、diallmp和hanglmp。新imp方法的增加不会影响到使用者。可以使用ISP来给连接控制类增加新的接口。这种做法可以创建出一条迁移路径，调制解调器的客户程序可以沿着这条路径慢慢地得到一个比dial和hangup层次更高的API。

五、 另外一个实际应用Bridge模式的例子

该例子演示了业务对象（BusinessObject）通过Bridge模式与数据对象（DataObject）解耦。数据对象的实现可以在不改变客户端代码的情况下动态进行更换。


// Bridge pattern -- Real World example


using System;


using System.Collections;




// "Abstraction"


class BusinessObject


{


// Fields


private DataObject dataObject;


protected string group;




// Constructors


public BusinessObject( string group )


{


this.group = group;


}




// Properties


public DataObject DataObject


{


set{ dataObject = value; }


get{ return dataObject; }


}




// Methods


virtual public void Next()


{ dataObject.NextRecord(); }




virtual public void Prior()


{ dataObject.PriorRecord(); }




virtual public void New( string name )


{ dataObject.NewRecord( name ); }




virtual public void Delete( string name )


{ dataObject.DeleteRecord( name ); }




virtual public void Show()


{ dataObject.ShowRecord(); }




virtual public void ShowAll()


{


Console.WriteLine( "Customer Group: {0}", group );


dataObject.ShowAllRecords();


}


}




// "RefinedAbstraction"


class CustomersBusinessObject : BusinessObject


{


// Constructors


public CustomersBusinessObject( string group )


: base( group ){}




// Methods


override public void ShowAll()


{


// Add separator lines


Console.WriteLine();


Console.WriteLine( "------------------------" );


base.ShowAll();


Console.WriteLine( "------------------------" );


}


}




// "Implementor"


abstract class DataObject


{


// Methods


abstract public void NextRecord();


abstract public void PriorRecord();


abstract public void NewRecord( string name );


abstract public void DeleteRecord( string name );


abstract public void ShowRecord();


abstract public void ShowAllRecords();


}




// "ConcreteImplementor"


class CustomersDataObject : DataObject


{


// Fields


private ArrayList customers = new ArrayList();


private int current = 0;




// Constructors


public CustomersDataObject()


{


// Loaded from a database


customers.Add( "Jim Jones" );


customers.Add( "Samual Jackson" );


customers.Add( "Allen Good" );


customers.Add( "Ann Stills" );


customers.Add( "Lisa Giolani" );


}




// Methods


public override void NextRecord()


{


if( current <= customers.Count - 1 )


current++;


}




public override void PriorRecord()


{


if( current > 0 )


current--;


}




public override void NewRecord( string name )


{


customers.Add( name );


}




public override void DeleteRecord( string name )


{


customers.Remove( name );


}




public override void ShowRecord()


{


Console.WriteLine( customers[ current ] );


}




public override void ShowAllRecords()


{


foreach( string name in customers )


Console.WriteLine( " " + name );


}


}




/// <summary>


/// Client test


/// </summary>


public class BusinessApp


{


public static void Main( string[] args )


{


// Create RefinedAbstraction


CustomersBusinessObject customers =


new CustomersBusinessObject(" Chicago ");




// Set ConcreteImplementor


customers.DataObject = new CustomersDataObject();




// Exercise the bridge


customers.Show();


customers.Next();


customers.Show();


customers.Next();


customers.Show();


customers.New( "Henry Velasquez" );




customers.ShowAll();


}


}

六、 在什么情况下应当使用桥梁模式

根据上面的分析，在以下的情况下应当使用桥梁模式：

如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

参考文献：

阎宏，《Java与模式》，电子工业出版社

[美]James W. Cooper，《C#设计模式》，电子工业出版社

[美]Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社

[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社

[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社

.NET设计模式（9）：桥接模式（Bridge Pattern）

桥接模式（Bridge Pattern）

——.NET设计模式系列之九
Terrylee，2006年2月
概述

在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。

意图

将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》]

结构图



图1 Bridge模式结构图
生活中的例子

桥接模式将抽象部分与它的实现分离，使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关，也可以是调光开关。



图2 使用电子开关例子的桥接对象图
桥接模式解说

在创建型模式里面，我曾经提到过抽象与实现，抽象不应该依赖于具体实现细节，实现细节应该依赖于抽象。看下面这幅图：



图3 抽象不应该依赖于实现细节
在这种情况下，如果抽象B稳定，而实现细节b变化，这时用创建型模式来解决没有问题。但是如果抽象B也不稳定，也是变化的，该如何解决？这就要用到Bridge模式了。

我们仍然用日志记录工具这个例子来说明Bridge模式。现在我们要开发一个通用的日志记录工具，它支持数据库记录DatabaseLog和文本文件记录FileLog两种方式，同时它既可以运行在.NET平台，也可以运行在Java平台上。

根据我们的设计经验，应该把不同的日志记录方式分别作为单独的对象来对待，并为日志记录类抽象出一个基类Log出来，各种不同的日志记录方式都继承于该基类：



图4 Log类结构图
实现代码如下：

public abstractclassLog
{
public
abstract void Write(string log);
}

public classDatabaseLog :Log
{
public
override void Write(string log)
{
//......Log Database
}
}

public classTextFileLog :Log
{
public
override void Write(string log)
{
//......Log Text File
}
}

另外考虑到不同平台的日志记录，对于操作数据库、写入文本文件所调用的方式可能是不一样的，为此对于不同的日志记录方式，我们需要提供各种不同平台上的实现，对上面的类做进一步的设计得到了下面的结构图：



图5
实现代码如下：

public classNDatabaseLog :DatabaseLog
{
public
override void Write(string log)
{
//......(.NET平台)Log Database
}
}

public classJDatabaseLog :DatabaseLog
{
public
override void Write(string log)
{
//......(Java平台)Log Database
}
}

public classNTextFileLog :TextFileLog
{
public
override void Write(string log)
{
//......(.NET平台)Log Text File
}
}

public classJTextFileLog :TextFileLog
{
public
override void Write(string log)
{
//......(Java平台)Log TextFile
}
}

现在的这种设计方案本身是没有任何错误的，假如现在我们要引入一种新的xml文件的记录方式，则上面的类结构图会变成：



图6
如图中蓝色的部分所示，我们新增加了一个继承于Log基类的子类，而没有修改其它的子类，这样也符合了开放-封闭原则。如果我们引入一种新的平台，比如说我们现在开发的日志记录工具还需要支持Borland平台，此时该类结构又变成了：



图7
同样我们没有修改任何的东西，只是增加了两个继承于DatabaseLog和TextFileLog的子类，这也符合了开放-封闭原则。

但是我们说这样的设计是脆弱的，仔细分析就可以发现，它还是存在很多问题，首先它在遵循开放-封闭原则的同时，违背了类的单一职责原则，即一个类只有一个引起它变化的原因，而这里引起Log类变化的原因却有两个，即日志记录方式的变化和日志记录平台的变化；其次是重复代码会很多，不同的日志记录方式在不同的平台上也会有一部分的代码是相同的；再次是类的结构过于复杂，继承关系太多，难于维护，最后最致命的一点是扩展性太差。上面我们分析的变化只是沿着某一个方向，如果变化沿着日志记录方式和不同的运行平台两个方向变化，我们会看到这个类的结构会迅速的变庞大。

现在该是Bridge模式粉墨登场的时候了，我们需要解耦这两个方向的变化，把它们之间的强耦合关系改成弱联系。我们把日志记录方式和不同平台上的实现分别当作两个独立的部分来对待，对于日志记录方式，类结构图仍然是：



图8
现在我们引入另外一个抽象类ImpLog，它是日志记录在不同平台的实现的基类，结构图如下：



图9
实现代码如下：

public abstractclassImpLog
{
public
abstract void Execute(string msg);
}

public classNImpLog :ImpLog
{
public
override void Execute(string msg)
{
//...... .NET平台
}
}

public classJImpLog :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 classDatabaseLog :Log
{
public
override void Write(string log)
{
implementor.Execute(log);
}
}

public classTextFileLog :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 classNDatabaseLog :DatabaseLog,IImpLog
{
//......
}
public classJDatabaseLog :DatabaseLog,IImpLog
{
//......
}
public classNTextFileLog :TextFileLog,IImpLog
{
//......
}

public classJTextFileLog :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桥接模式(结构型模式)》

设计模式随笔－蜡笔与毛笔的故事

我想大家小时候都有用蜡笔画画的经历吧。红红绿绿的蜡笔一大盒，根据想象描绘出格式图样。而毛笔下的国画更是工笔写意，各展风采。而今天我们的故事从蜡笔与毛笔说起。

设想要绘制一幅图画，蓝天、白云、绿树、小鸟，如果画面尺寸很大，那么用蜡笔绘制就会遇到点麻烦。毕竟细细的蜡笔要涂出一片蓝天，是有些麻烦。如果有可能，最好有套大号蜡笔，粗粗的蜡笔很快能涂抹完成。至于色彩吗，最好每种颜色来支粗的，除了蓝天还有绿地呢。这样，如果一套12种颜色的蜡笔，我们需要两套24支，同种颜色的一粗一细。呵呵，画还没画，开始做梦了：要是再有一套中号蜡笔就更好了，这样，不多不少总共36支蜡笔。



再看看毛笔这一边，居然如此简陋：一套水彩12色，外加大中小三支毛笔。你可别小瞧这"简陋"的组合，画蓝天用大毛笔，画小鸟用小毛笔，各具特色。



呵呵，您是不是已经看出来了，不错，我今天要说的就是Bridge模式。为了一幅画，我们需要准备36支型号不同的蜡笔，而改用毛笔三支就够了，当然还要搭配上12种颜料。通过Bridge模式，我们把乘法运算3×12＝36改为了加法运算3＋12＝15，这一改进可不小。那么我们这里蜡笔和毛笔到底有什么区别呢？

实际上，蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。【GOF95】桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不开的，所以就造成必须使用36支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦，各自独立变化，便简化了操作。在这里，抽象层面的概念是："毛笔用颜料作画"，而在实现时，毛笔有大中小三号，颜料有红绿蓝等12种，于是便可出现3×12种组合。每个参与者（毛笔与颜料）都可以在自己的自由度上随意转换。

蜡笔由于无法将笔与颜色分离，造成笔与颜色两个自由度无法单独变化，使得只有创建36种对象才能完成任务。Bridge模式将继承关系转换为组合关系，从而降低了系统间的耦合，减少了代码编写量。但这仅仅是Bridge模式带来的众多好处的一部分，更多层面的内容，请参考《设计模式（16）－Bridge
Pattern》。

本文代码附于此处：


using System;




abstract class Brush


{


protected Color c;


public abstract void Paint();




public void SetColor(Color c)


{ this.c = c; }


}




class BigBrush : Brush


{


public override void Paint()


{ Console.WriteLine("Using big brush and color {0} painting

", c.color); }


}




class SmallBrush : Brush


{


public override void Paint()


{ Console.WriteLine("Using small brush and color {0} painting

", c.color); }


}




class Color


{


public string color;


}




class Red : Color


{


public Red()


{ this.color = "red"; }


}




class Blue : Color


{


public Blue()


{ this.color = "blue"; }


}




class Green : Color


{


public Green()


{ this.color = "green"; }


}




class Client


{


public static void Main()


{


Brush b = new BigBrush();


b.SetColor(new Red());


b.Paint();


b.SetColor(new Blue());


b.Paint();


b.SetColor(new Green());


b.Paint();




b = new SmallBrush();


b.SetColor(new Red());


b.Paint();


b.SetColor(new Blue());


b.Paint();


b.SetColor(new Green());


b.Paint();


}


}

Bridge Strategy 和State的区别

Bridge Strategy 和State的区别

首先需要申明的是本文不是介绍Bridge Strategy
和State模式，而是讨论它们的区别，所以需要你对它们先有所了解。

Bridge模式用一句话来说就是将抽象和实现分离。这句话如何理解，在《Design Pattern Explained》一书中做了很详细的解释。说实话，我现在已经记不清它是怎么说的了。

吕震宇对此也做了解释。

我是这样理解的：对一个事物进行抽象，得到了一个行为。比如对Shape进行抽象，得到了Draw的行为。Draw是在哪里实现的？不是在它抽象而来的类Shape，而是在另外一个类实现的。哪个类呢？Drawing类。

Draw是从Shape抽象出来的行为，但是不在Shape中予以实现。这就是抽象和实现分离。

为什么要这样呢？因为Draw的方法可能不同，比如可以用实线，也可以用虚线。为了更好的隐藏变化，所以将其分离。由于本文不是介绍Bridge模式，不再深入介绍它的好处。



（BTW在吕震宇的文章中似乎并不是Bridge模式，因为缺少被抽象的行为，但是具有Bridge模式的思想Favor
composition than inheritance，不过在这三个模式中都有这个思想，所以大家很难分清。）

说到这里，你有没有想到Template Method模式。为什么不用它来实现？

错！ Template Method重在Template。你这里只是根据不同的方法（实线，虚线）重写Draw方法。那个Template方法你并没用到。

这样我们就引出了Bridge和Strategy的区别。

Bridge就是将抽象出的行为交给别人做，抽象方法中就是一个简单的委托，没有使用模板方法。

而Strategy就是有模板方法的Bridge。如下：



所以区别的关键在于那个抽象方法是不是Template方法。

再来看Strategy和State模式。同样这里不会细谈State模式，相关内容可以见DP。（State模式主要描述的是有限自动机的思想）

其实这两个模式区别比较大，不过在Gof的图中没体现出来。

就拿DP书中的例子来说：



关键就在于那个TCPState对TCPConnection的引用。

为什么书中没有这条线？因为TCPConnection是作为函数参数（Open(TCPConnection tp)）传给TCPState的。TCPState本身并没有TCPConnection的引用。

为什么要有这条线，在这里强调的是在各个方法中会改变TCP连接的状态。比如当目前TCP连接处于Closed状态，那么调用Open自然会改变当前的状态使之变为TCPEstablished，而要想改变TCPConnection的state对象，自然要传入TCPConnection的引用，然后调用SetState方法。

另外要说的是TCPConnection中的状态的变化是由TCPState来控制的，其他任何对象都不应该控制。也就是说SetState函数也只能有TCPState来调用。（其实这里应该采用类似C++友元的机制比较好）而Stradegy中的具体算法是由外界设置和改变的，而不是模式的内部活动。

现在你明白他们的区别了吗？比你相像的要大吧。

不过他们的目的都是两个：

Find what vary and encapsulate it.

Favor composition than inheritance.

乐在其中设计模式(C#) - 桥接模式(Bridge Pattern)

[align=center]乐在其中设计模式(C#) - 桥接模式(Bridge Pattern)[/align]

作者：webabcd

介绍

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

示例

有一个Message实体类，对它的操作有Insert()和Get()方法，现在使这些操作的抽象部分和实现部分分离。



MessageModel


using System;


using System.Collections.Generic;


using System.Text;




namespace Pattern.Bridge


{


/// <summary>


/// Message实体类


/// </summary>


public class MessageModel


{


/// <summary>


/// 构造函数


/// </summary>


/// <param name="msg">Message内容</param>


/// <param name="pt">Message发布时间</param>


public MessageModel(string msg, DateTime pt)


{


this._message = msg;


this._publishTime = pt;


}




private string _message;


/// <summary>


/// Message内容


/// </summary>


public string Message


{


get { return _message; }


set { _message = value; }


}




private DateTime _publishTime;


/// <summary>


/// Message发布时间


/// </summary>


public DateTime PublishTime


{


get { return _publishTime; }


set { _publishTime = value; }


}


}


}



Message


using System;


using System.Collections.Generic;


using System.Text;




namespace Pattern.Bridge


{


/// <summary>


/// 操作Message（Abstraction）


/// </summary>


public class Message


{


private AbstractMessage _abstractMessage;


/// <summary>


/// 操作Message（Implementor）


/// </summary>


public AbstractMessage AbstractMessage


{


get { return _abstractMessage; }


set { _abstractMessage = value; }


}




/// <summary>


/// 获取Message


/// </summary>


/// <returns></returns>


public virtual List<MessageModel> Get()


{


return _abstractMessage.Get();


}




/// <summary>


/// 插入Message


/// </summary>


/// <param name="mm">Message实体对象</param>


/// <returns></returns>


public virtual bool Insert(MessageModel mm)


{


return _abstractMessage.Insert(mm);


}


}


}



MyMessage


using System;


using System.Collections.Generic;


using System.Text;




namespace Pattern.Bridge


{


/// <summary>


/// 操作Message（RefinedAbstraction）


/// </summary>


public class MyMessage : Message


{


/// <summary>


/// 获取Message


/// </summary>


/// <returns></returns>


public override List<MessageModel> Get()


{


List<MessageModel> l = base.Get();




foreach (MessageModel mm in l)


{


mm.Message += "（RefinedAbstraction）";


}




return l;


}


}


}



AbstractMessage


using System;


using System.Collections.Generic;


using System.Text;




namespace Pattern.Bridge


{


/// <summary>


/// 操作Message（Implementor）


/// </summary>


public abstract class AbstractMessage


{


/// <summary>


/// 获取Message


/// </summary>


/// <returns></returns>


public abstract List<MessageModel> Get();




/// <summary>


/// 插入Message


/// </summary>


/// <param name="mm">Message实体对象</param>


/// <returns></returns>


public abstract bool Insert(MessageModel mm);


}


}



SqlMessage


using System;


using System.Collections.Generic;


using System.Text;




namespace Pattern.Bridge


{


/// <summary>


/// Sql方式操作Message（ConcreteImplementor）


/// </summary>


public class SqlMessage : AbstractMessage


{


/// <summary>


/// 获取Message


/// </summary>


/// <returns></returns>


public override List<MessageModel> Get()


{


List<MessageModel> l = new List<MessageModel>();


l.Add(new MessageModel("SQL方式获取Message", DateTime.Now));




return l;


}




/// <summary>


/// 插入Message


/// </summary>


/// <param name="mm">Message实体对象</param>


/// <returns></returns>


public override bool Insert(MessageModel mm)


{


// 代码略


return true;


}


}


}



XmlMessage


using System;


using System.Collections.Generic;


using System.Text;




namespace Pattern.Bridge


{


/// <summary>


/// Xml方式操作Message（ConcreteImplementor）


/// </summary>


public class XmlMessage : AbstractMessage


{


/// <summary>


/// 获取Message


/// </summary>


/// <returns></returns>


public override List<MessageModel> Get()


{


List<MessageModel> l = new List<MessageModel>();


l.Add(new MessageModel("XML方式获取Message", DateTime.Now));




return l;


}




/// <summary>


/// 插入Message


/// </summary>


/// <param name="mm">Message实体对象</param>


/// <returns></returns>


public override bool Insert(MessageModel mm)


{


// 代码略


return true;


}


}


}



Test


using System;


using System.Data;


using System.Configuration;


using System.Collections;


using System.Web;


using System.Web.Security;


using System.Web.UI;


using System.Web.UI.WebControls;


using System.Web.UI.WebControls.WebParts;


using System.Web.UI.HtmlControls;




using Pattern.Bridge;




public partial class Bridge : System.Web.UI.Page


{


protected void Page_Load(object sender, EventArgs e)


{


MyMessage m = new MyMessage();




m.AbstractMessage = new SqlMessage();




Response.Write(m.Insert(new MessageModel("插入", DateTime.Now)));


Response.Write("<br />");


Response.Write(m.Get()[0].Message + " " + m.Get()[0].PublishTime.ToString());


Response.Write("<br />");




m.AbstractMessage = new XmlMessage();




Response.Write(m.Insert(new MessageModel("插入", DateTime.Now)));


Response.Write("<br />");


Response.Write(m.Get()[0].Message + " " + m.Get()[0].PublishTime.ToString());


}


}



运行结果

True

SQL方式获取Message（RefinedAbstraction） 2007-5-13 19:11:19

True

XML方式获取Message（RefinedAbstraction） 2007-5-13 19:11:19

参考

http://www.dofactory.com/Patterns/PatternBridge.aspx

OK

[源码下载]