第7章 桥接模式（Bridge Pattern）

原文 第7章 桥接模式（Bridge Pattern）

定义：

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

意图：

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

结构图：

举例：KFC中的可乐，

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

abstract class KFCFood     {         //可乐         public abstract void KeLe();              }     //冰镇可乐     class IcedKeLe : KFCFood     {         public override void KeLe()         {              //冰镇可乐         }     }     //常温可乐     class NormalKeLe : KFCFood     {         public override void KeLe()         {             //常温可乐         }     }     //大杯冰镇可乐     class LargeIcedKeLe : IcedKeLe     {         public override void KeLe()         {             //大杯冰镇可乐         }     }     //小杯冰镇可乐     class SmallIcedKeLe : IcedKeLe     {         public override void KeLe()         {             //小杯冰镇可乐         }     }       //大杯常温可乐     class LargeNormalKeLe : NormalKeLe     {         public override void KeLe()         {             //大杯常温可乐         }     }       //小杯常温可乐     class SmallNormalKeLe : NormalKeLe     {         public override void KeLe()         {             //小杯常温可乐         }     }           //client     class Program     {         static void Main(string[] args)         {             //小杯冰镇可乐             SmallIcedKeLe keLe = new SmallIcedKeLe();             keLe.KeLe();             }     }

在上面的例子中我们要的是小杯的冰镇可乐，这个是两个维度（小杯，冰镇）。好假如我们现在要一小杯美国的冰镇可乐（三个维度，美国，小杯，冰镇），这里我们假设可乐有分国籍的（比如：美国可乐，中国可乐等）。

我们又得写好几个类来继承这个美国版的冰镇可乐，如果我们要中国的冰镇可乐，那又得写一大堆的类，而且里面重复的非常多

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

//美国冰镇可乐，后面的大杯冰镇可乐，小杯冰镇可乐也都得继承这个类     class AmericaIcedKeLe : IcedKeLe     {         public override void KeLe()         {             //美国冰镇可乐         }     }     //小杯美国冰镇可乐     class AmericaSmallIcedKeLe : IcedKeLe     {         public override void KeLe()         {             //小杯美国冰镇可乐         }     }

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

下面我们用桥模式来重新设计：

向我们先增加一个品牌类

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

//品牌     abstract class Brand     {             public abstract void KeLe();           }       //美国可乐     class AmericaIcedKeLe : Brand     {         public override void KeLe()         {             //美国可乐         }     }

修改原有的基类

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

abstract  class KFCFood     {         protected Brand brand;           public Brand Brand {             get {                 return brand;             }             set {                 brand = value;             }         }         //可乐         public abstract void KeLe();              }                     //冰镇可乐     class IcedKeLe : KFCFood     {         public override void KeLe()         {             //冰镇可乐             brand.KeLe();                    }     }                     //小杯常温可乐     class SmallIcedKeLe: IcedKeLe      {         public override void KeLe()         {             //小杯冰镇可乐             brand.KeLe();         }     }                  class Program     {         static void Main(string[] args)         {             //小杯美国牌冰镇可乐             KFCFood AmericaKeLe = new SmallIcedKeLe();             AmericaKeLe.KeLe();           }     }

下次如果来中国牌可乐。非洲可乐，只需要增加一个类继承Brand这个类就行了，不需要重复的去写子类。是不是感觉方便了很多！

实现要点

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

2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。

3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。

4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用场景

在以下的情况下应当使用桥模式：

1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。

2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。

3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。

4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

设计模式系列文章入口