你的位置:首页 > ASP.net教程

[ASP.net教程]设计模式07: Bridge 桥接模式(结构型模式)


Bridge 桥接模式(结构型模式)

抽象与实现

抽象不应该依赖于实现细节,实现细节应该依赖于抽象。

抽象B稳定,实现细节b变化

问题在于如果抽象B由于固有的原因,本身并不稳定,也有可能变化,怎么办?

 

举例来说

  假如我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的需求变化,比如坦克可能有多种不同的型号:T50,T75,T90……

对于其中坦克设计,我们可能很容易设计出来一个Tank的抽象基类:

  /// <summary>  /// 抽象Tank  /// </summary>  public abstract class Tank  {    public abstract void Shot();    public abstract void Run();    public abstract void Turn();  }  //各种实现  public class T50 : Tank  {    //……  }  public class T75 : Tank  {    //……  }  public class T90 : Tank  {    //……  }

另外的变化原因

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

  //PC平台实现  public class PCT50 : T50  {    //……  }  public class PCT75 : T75  {    //……  }  public class PCT90 : T90  {    //……  }  //手机平台实现  public class MobileT50 : T50  {    //……  }  public class MobileT75 : T75  {    //……  }  public class MobileT90 : T90  {    //……  }

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

 

动机(Motivation)

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

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

 

意图(Intent)

将抽象部分与现实部分分离,使它们可以独立地变化。——《设计模式》GoF

 

代码示例:

  //平台  public abstract class TankPlatformImplementation  {    public abstract void MoveTankTo(Point to);    public abstract void DrawTank();    public abstract void DoShot();  }  //PC平台  public class PCTankImplementation : TankPlatformImplementation  {    public override void MoveTankTo(Point to)    {      //……    }    public override void DrawTank()    {      //……    }    public override void DoShot()    {      //……    }  }  //手机平台  public class MobileTankImplementation : TankPlatformImplementation  {    public override void MoveTankTo(Point to)    {      //……    }    public override void DrawTank()    {      //……    }    public override void DoShot()    {      //……    }  }

  /// <summary>  /// 抽象Tank  /// </summary>  public abstract class Tank  {    protected TankPlatformImplementation tankImpl;    public Tank(TankPlatformImplementation tankImpl)    {      this.tankImpl = tankImpl;    }    public TankPlatformImplementation TankImpl    {      get { return this.tankImpl; }      set { this.tankImpl = tankImpl; }    }    public abstract void Shot();    public abstract void Run();    public abstract void Turn();  }

  //各种实现  public class T50 : Tank  {    public T50(TankPlatformImplementation tankImpl):base(tankImpl)    {            }    public override void Shot()    {      //……    }    public override void Run()    {      //……    }    public override void Turn()    {      //……    }  }  public class T75 : Tank  {    public T75(TankPlatformImplementation tankImpl):base(tankImpl)    {            }    public override void Shot()    {      //……    }    public override void Run()    {      //……    }    public override void Turn()    {      //……    }  }  public class T90 : Tank  {    public T90(TankPlatformImplementation tankImpl):base(tankImpl)    {            }    public override void Shot()    {      //……    }    public override void Run()    {      //……    }    public override void Turn()    {      //……    }  }

  //调用  public class App  {    public static void Main()    {      TankPlatformImplementation tankImpl=new MobileTankImplementation();//手机平台调用      T50 tankT50=new T50(tankImpl);    }  }

将一个事物中多个维度的变化分离,使它们可以独立地变化

Bridge模式的几个要点

Bridge模式使用“对象间的组合关系”解耦了抽象和现实之间固有的绑定关系,使得抽象(Tank的型号)和实现(不同的平台)可以沿着各自的维度来变化。

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

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

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