设计模式：桥接模式（Bridge Pattern）

作者：TerryLee 创建于：2006-02-24 出处：http://terrylee.cnblogs.com/archive/2006/02/24/336652.html 收录于：2013-02-28

结构图

概述

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

意图

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

适用性

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

桥接模式解说

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

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

下面仍然举log的例子：

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

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

如果我们引入一种新的平台，比如说我们现在开发的日志记录工具还需要支持Borland平台，此时该类结构又变成了：

这也符合了开放-封闭原则。

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

上面我们分析的变化只是沿着某一个方向，如果变化沿着日志记录方式和不同的运行平台两个方向变化，我们会看到这个类的结构会迅速的变庞大。

代码实现

 1 using System;
 2 public abstract class ImpLog
 3 {
 4     public abstract void Execute(string msg);
 5 }
 6 public class NImpLog : ImpLog
 7 {
 8     public override void Execute(string msg)
 9     {
10         //...... .NET平台
11     }
12 }
13 public class JImpLog : ImpLog
14 {
15     public override void Execute(string msg)
16     {
17         //...... Java平台
18     }
19 }
20
21 public abstract class Log
22 {
23     protected ImpLog implementor;
24     public ImpLog Implementor
25     {
26         set { implementor = value; }
27     }
28     public virtual void Write(string log)
29     {
30         implementor.Execute(log);
31     }
32 }
33 public class DatabaseLog : Log
34 {
35     public override void Write(string log)
36     {
37         implementor.Execute(log);
38     }
39 }
40 public class TextFileLog : Log
41 {
42     public override void Write(string log)
43     {
44         implementor.Execute(log);
45     }
46 }
47 class App
48 {
49     public static void Main(string[] args)
50     {
51         //.NET平台下的Database
52         Log dblog = new DatabaseLog();
53         dblog.Implementor = new NImpLog();
54         dblog.Write();
55         //Java平台下的Text File Log
56         Log txtlog = new TextFileLog();
57         txtlog.Implementor = new JImpLog();
58         txtlog.Write();
59     }
60 }

效果及实现要点

1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。

2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

转载于:https://www.cnblogs.com/Ming8006/archive/2013/02/28/2937265.html