抽象与实现
    抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
动机（Motivation）
    思考上述问题的症结：事实上由于Tank类型的固有逻辑，使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”，一个变化的维度为“型号的变化”。
    如何应对这种“多维度的变化”？如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化，而不引入额外的复杂度？

桥梁模式的用意

【GOF95】在提出桥梁模式的时候指出，桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。这句话有三个关键词，也就是抽象化、实现化和脱耦。

脱耦

所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。这就是桥梁模式的用意。

namespace Bridge1
{
    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 Stop();
    }


    /// <summary>
    /// 用子类化来表达变化,是面向对象一个常用的做法
    /// </summary>
    public abstract class TankPlatformImplementation
    {
        public abstract void MoveTankTo(Point to)
        { 
        }
        public abstract void DrawTank()
        { 
            
        }

        public abstract void DoShot()
        { 
            
        }

    }

    public class PCTankImplementation : TankPlatformImplementation
    {
        public override void MoveTankTo(Point to)
        {
            //..
        }
        public override void DoShot()
        {
            //
        }
        public override void DrawTank()
        {
            
            //..
        }
    }

    public class MobileTankImplementation : TankPlatformImplementation
    {
        public override void MoveTankTo(Point to)
        {
            //..
        }
        public override void DoShot()
        {
            //
        }
        public override void DrawTank()
        {
            //.
        }

    }

    public class T50 : Tank
    {
        //继承可能成为的变化点
        public T50(TankPlatformImplementation tankImpl)
            : base(tankImpl)
        { 
        
        }

        public override void Shot()
        {
            //.T50
            TankImpl.DoShot();

        }
        public override void Run()
        {
            //T50
        }
        public override void Stop()
        {
            //.T50
        }
    }

    public class T75 : Tank
    {
        public T75(TankPlatformImplementation tankImpl)
            : base(tankImpl)
        { }
        public override void Shot()
        {
            //.T75
            TankImpl.DoShot();

        }
        public override void Run()
        {
            //T75
        }
        public override void Stop()
        {
            //.T75
        }
    }

    public class T90 : Tank
    {
        public T90(TankPlatformImplementation tankImpl)
            : base(tankImpl)
        { 
        
        }
        public override void Shot()
        {
            //T90
            TankImpl.DoShot();
        }

        public override void Run()
        {
            //T90
        }
        public override void Stop()
        {
            //.T90
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            TankPlatformImplementation tankImpl = new MobileTankImplementation();

            T50 tank = new T50(tankImpl);

        }
    }
    
}

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