设计模式——桥接模式

桥接模式即将抽象部分与它的实现部分分离开来，使他们都可以独立变化。
桥接模式将继承关系转化成关联关系，它降低了类与类之间的耦合度，减少了系统中类的数量，也减少了代码量,桥接模式直白的说就是将深度垂直继承关系拉平转化成横向的一对多或者多对多关联关系
生活场景：
就拿汽车在路上行驶的来说。即有小汽车又有公共汽车，它们都不但能在市区中的公路上行驶，也能在高速公路上行驶。这你会发现，对于交通工具（汽车）有不同的类型，然而它们所行驶的环境（路）也在变化，在软件系统中就要适应两个方面的变化？怎样实现才能应对这种变化呢？
传统设计方式：
设计图：

代码实现:

namespace Designer.BridgePattern
{

    //路的基类;
    public class Road
    {
        public virtual void Run()
        {
            Console.WriteLine("在路上");
        }
    }
    //高速公路;
    public class SpeedWay : Road
    {
        public override void Run()
        {
            Console.WriteLine("高速公路");
        }
    }
    //市区街道;
    public class Street : Road
    {
        public override void Run()
        {
            Console.WriteLine("市区街道");
        }
    }
    //小汽车在高速公路上行驶;
    public class CarOnSpeedWay : SpeedWay
    {
        public override void Run()
        {
            Console.WriteLine("小汽车在高速公路上行驶");
        }
    }
    //公共汽车在高速公路上行驶;
    public class BusOnSpeedWay : SpeedWay
    {
        public override void Run()
        {
            Console.WriteLine("公共汽车在高速公路上行驶");
        }
    }
    //小汽车在市区街道上行驶;
    public class CarOnStreet : Street
    {
        public override void Run()
        {
            Console.WriteLine("汽车在街道上行驶");
        }
    }
    //公共汽车在市区街道上行驶;
    public class BusOnStreet : Street
    {
        public override void Run()
        {
            Console.WriteLine("公共汽车在街道上行驶");
        }
    }


}

客户端调用:

static void Main(string[] args)
  {
       //小汽车在高速公路上行驶
       CarOnSpeedWay Car = new CarOnSpeedWay();
       Car.Run();

       Console.WriteLine("===========================");

       //公共汽车在街道上行驶
       BusOnStreet Bus = new BusOnStreet();
       Bus.Run();

       Console.Read();
   }

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

道路实现：

namespace Designer.BridgePattern
{

    //抽象路
    public abstract class AbstractRoad
    {
        protected AbstractCar car;
        public AbstractCar Car
        {
            set
            {
                car = value;
            }
        }

        public abstract void Run();
    }

    //高速公路
    public partial class SpeedWay : AbstractRoad
    {
        public override void Run()
        {
            car.Run();
            Console.WriteLine("高速公路上行驶");
        }
    }

    //市区街道
    public class Street : AbstractRoad
    {
        public override void Run()
        {
            car.Run();
            Console.WriteLine("市区街道上行驶");
        }
    }
}

车子抽象：

namespace Designer.BridgePattern
{
    //抽象汽车 
    public abstract class AbstractCar
    {
        public abstract void Run();
    }

    //小汽车;
    public class Car : AbstractCar
    {
        public override void Run()
        {
            Console.Write("小汽车在");
        }
    }

    //公共汽车
    public class Bus : AbstractCar
    {
        public override void Run()
        {
            Console.Write("公共汽车在");
        }
    }
}

客户端调用：

static void Main(string[] args)
 {
     //小汽车在高速公路上行驶;
     AbstractRoad Road1 = new SpeedWay();
     Road1.Car = new Car();
     Road1.Run();
     Console.WriteLine("=========================");

     //公共汽车在高速公路上行驶;
     AbstractRoad Road2 = new SpeedWay();
     Road2.Car = new Bus();
     Road2.Run();
     Console.Read();
 }

可以看到，通过对象组合的方式，Bridge 模式把两个角色之间的继承关系改为了耦合的关系，从而使这两者可以从容自若的各自独立的变化，这也是Bridge模式的本意。
这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的，因为这种耦合性是由于对象的创建所带来的，完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。
具体应用：
桥接模式（Bridge）来做(多维度变化);
结合上面的例子,增加一个维度”人”,不同的人开着不同的汽车在不同的路上行驶(三个维度);
结合上面增加一个类”人”,并重新调用.

namespace Designer.BridgePattern
{
    abstract class People
    {
        AbstractRoad road;
        public AbstractRoad Road
        {
            get
            {
                return road;
            }
            set
            {
                road = value;
            }
        }
        public abstract void Run();

    }
    class Man : People
    {
        public override void Run()
        {
            Console.Write("男人开着");
            Road.Run();
        }
    }

    class WoMan : People
    {
        public override void Run()
        {
            Console.Write("女人开着");
            Road.Run();
        }
    }
}

客户端调用:

 static void Main(string[] args)
   {
       //男人开着公共汽车在高速公路上行驶;
       Console.WriteLine("=========================");

       AbstractRoad Road3 = new SpeedWay();
       Road3.Car = new Bus();

       People p = new Man();
       p.Road = Road3;
       p.Run();

       Console.Read();
   }

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

适用性：
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

转载：
设计模式—–桥接模式(Bridge Pattern)