设计模式学习笔记（八）Bridge桥接（结构型模式）

抽象与实现

根据依赖倒置原则，抽象不应该依赖于实现细节，实现细节应该依赖于抽象。抽象A依赖于抽象B，实现细节b也依赖于抽象B。这要求是抽象B比较稳定，实现细节b倾向于变化。问题是：如果抽象B由于固有的原因，本身并不稳定，也有可能变化，怎么办？

举例：

如果要开发一个同时支持PC和手机的坦克游戏，游戏在PC和手机上功能都一样，都有同样的类型，面临同样的功能需求变化，比如坦克可能有多种不同的型号：T50，T75，T90...对于其中的坦克设计，我们可能很容易设计出来一个Tank的抽象基类，然后各种不同型号的Tank继承自该类：

public abstract class Tank{

 public abstract void Shot();
 public abstract void Run();
 public abstract void Trun();
 
}

public class T50:Tank{...}

但是PC和手机上的图形绘制、声效、操作等实现完全不同...因此对于各种型号的坦克，都要提供各种不同平台上的坦克实现：

//PC平台实现
public class PCT50:T50{...}
//手机平台实现
public class MobileT50:T50{...}

这样的设计会带来很多问题，有很多重复代码，类的结构过于复杂，难以维护。最致命的是引入任何新平台，比如在TV上的Tank游戏，都会让整个类层级结构复杂化。

 

Bridge模式的动机（Motivation）

上述问题的症结在于：事实上由于Tank类型的固有逻辑，使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”，一个变化的维度为“型号的变化”。

如何应对这种“多维度的变化”？如何利用面向对象的技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化，而不引入额外的复杂度？

意图（Intent）

将抽象部分与实现部分分离，使它们都可以独立地变化。
                    ——《设计模式》GoF
                   
注意：这里的“实现部分”也可能是抽象的。抽象部分与实现部分可理解为“一个事物中多个维度的变化”。于是模式意图理解为：将一个事物中多个维度的变化分离，使它们都可以独立地变化。

 

代码Demo：

 

public abstract class Tank
{
 protected TankPlatformImplementation tankImpl;
 
 public Tank(TankPlatformImplementation tankImpl)
 {
  this.tankImpl = tankImpl;
 }
 
 public TankPlatformImplementation TankImpl
 {
  get
  {
   return this.tankImpl;
  }
  set
  {
   this.tankImpl = value;
  }
 
 }
 
 
 public abstract void Shot();
 public abstract void Run();
 public abstract void Stop();
 
}

public abstract class TankPlatformImplementation
{
 public abstract void MoveTank(Point to);
 
 public abstract void DrawTank();
 
 public abstract void DoShot();
 
}

public class PCTankImplementation:TankPlatformImplementation
{

 //实现PC平台
 //...
 //
}

 

public class T50:Tank

{
 //委托初始化方式
 public T50(TankPlatformImplementation tankImpl)
 :base(tankImpl)
 {
  //...
 }
 
 public override void Shot()
 {
  //...
  tankImpl.DoShot();
  //...
 }
 
 public override void Run()
 {
  //...
  //tankImpl.Move...
  //
 }
 
 public override void Stop()
 {
  //...
  //tankImpl...
  //
 }
}

//以上代码通过组合的形式将变化引出，避免了继承带来的紧耦合和类型“爆炸”。也使得Tank可以沿着“平台”和“型号”变化。

public class App

{

 public static void Main()
 {
  TankPlatformImplementation tankImpl = new PCTankImplementation();
  T50 tank = new T50(tankImpl);
  
 }
}

Bridge模式的几个要点

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