设计模式探索系列之Bridge模式
现在该是Bridge模式粉墨登场的时候了，我们需要解耦这两个方向的变化，把它们之间的强耦合关系改成弱联系。我们把日志记录方式和不同平台上的实现分别当作两个独立的部分来对待，对于日志记录方式，类结构图仍然是：
图8
现在我们引入另外一个抽象类ImpLog，它是日志记录在不同平台的实现的基类，结构图如下：
图9
实现代码如下：
这时对于日志记录方式和不同的运行平台这两个类都可以独立的变化了，我们要做的工作就是把这两部分之间连接起来。那如何连接呢？在这里，Bridge使用了对象组合的方式，类结构图如下：
图 10
实现代码如下：注意这里的Class Log就起到了桥接的作用它保证了类的单一职责即一个类引起它变化的原因只能有一个这里就是一个过渡的作用
可以看到，通过对象组合的方式，Bridge模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。再来看一下客户端如何去使用：
可能有人会担心说，这样不就又增加了客户程序与具体日志记录方式之间的耦合性了吗？其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决，就不是这里我们所讨论的内容了。
最后我们再来考虑一个问题，为什么Bridge模式要使用对象组合的方式而不是用继承呢？如果采用继承的方式，则Log类，ImpLog类都为接口，类结构图如下：
图11
实现代码如下：
如上图中蓝色的部分所示，它们既具有日志记录方式的特性，也具有接口IimpLog的特性，它已经违背了面向对象设计原则中类的单一职责原则，一个类应 当仅有一个引起它变化的原因。所以采用Bridge模式往往是比采用多继承更好的方案。说到这里，大家应该对Bridge模式有一些认识了吧？如果在开发 中遇到有两个方向上纵横交错的变化时，应该能够想到使用Bridge模式，当然了，有时候虽然有两个方向上的变化，但是在某一个方向上的变化并不是很剧烈 的时候，并不一定要使用Bridge模式。
效果及实现要点
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
适用性
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
总结
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
实现代码如下：注意这里的Class Log就起到了桥接的作用它保证了类的单一职责即一个类引起它变化的原因只能有一个这里就是一个过渡的作用
| 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模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则