Bridge 桥接（结构型模式）

场景
  一个游戏中的坦克Tank，有多种类型如：T50,T70,T90。我们通常的做法是有一个抽象的Tank基类，然后派生不同的类型的Tank。再进一步，如果此游戏需要适应PC，手机等不同的平台，则需要表示成PCT50:T50:Tank等形式了。这样带来的成本巨大的，当增加一种平台或增加一种坦克类型改动都很大。
问题
  实际上，由于Tank类型的固有逻辑，使得Tank类型具有了两个变化的维度，一个是“平台的变化”，一个是“型号的变化”。
  如何应对这种“多维度的变化”？发只可利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化，而不引入额外的复杂度？
定义
  将抽象部分与实现部分分离，使它们都可以独立地变化。
UML

代码
//bridge1.cs
class abstract Tank
{
  public abstract void Shot();
  public abstract void Run();
  public abstract void Stop();
}
public class T50:Tank
{
}
public class T70:Tank
{
}
public class T90:Tank
{
}
//pc
public class PCT50:T50
{
}
public class PCT70:T70
{
}
public class PCT90:T90
{
}
//mobile
public class MobileT50:T50
{
}
public class MobileT70:T70
{
}
public class MobileT90:T90
{
}

//bridge2.cs
class abstract Tank
{
  protected TankPlatform tankPf;
 
  public Tank(TankPlatform tp)
  {
     tankPf = tp;
  }

  public abstract void Shot();
  public abstract void Run();
  public abstract void Stop();
}
class abstract TankPlatform
{
   public abstract void Move();
}
class T50:Tank
{
 
}
class T70:Tank
{
 
}
class T90:Tank
{
 
}

//pc
public class PCTank:TankPlatform
{
}
//mobile
public class MobileTank:TankPlatform
{
}

public class App
{
  public static void Main()
  {
    
  }
}

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