桥接模式

1.蜡笔与毛笔的故事(引用自http://www.cnblogs.com/zhenyulu/articles/67016.html)

我想大家小时候都有用蜡笔画画的经历吧。红红绿绿的蜡笔一大盒，根据想象描绘出各式图样。而毛笔下的国画更是工笔写意，各展风采。而今天我们的故事从蜡笔与毛笔说起。设想要绘制一幅图画，蓝天、白云、绿树、小鸟，如果画面尺寸很大，那么用蜡笔绘制就会遇到点麻烦。毕竟细细的蜡笔要涂出一片蓝天，是有些麻烦。如果有可能，最好有套大号蜡笔，粗粗的蜡笔很快能涂抹完成。至于色彩吗，最好每种颜色来支粗的，除了蓝天还有绿地呢。这样，如果一套12种颜色的蜡笔，我们需要两套24支，同种颜色的一粗一细。呵呵，画还没画，开始做梦了：要是再有一套中号蜡笔就更好了，这样，不多不少总共36支蜡笔。

再看看毛笔这一边，居然如此简陋：一套水彩12色，外加大中小三支毛笔。你可别小瞧这"简陋"的组合，画蓝天用大毛笔，画小鸟用小毛笔，各具特色。

呵呵，您是不是已经看出来了，不错，这就是Bridge模式。为了一幅画，我们需要准备36支型号不同的蜡笔，而改用毛笔三支就够了，当然还要搭配上12种颜料。通过Bridge模式，我们把乘法运算3×12＝36改为了加法运算3＋12＝15，这一改进可不小。那么我们这里蜡笔和毛笔到底有什么区别呢？

实际上，蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。【GOF95】桥梁模式的用意是"将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不开的，所以就造成必须使用36支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦，各自独立变化，便简化了操作。在这里，抽象层面的概念是："毛笔用颜料作画"，而在实现时，毛笔有大中小三号，颜料有红绿蓝等12种，于是便可出现3×12种组合。每个参与者（毛笔与颜料）都可以在自己的自由度上随意转换。

蜡笔由于无法将笔与颜色分离，造成笔与颜色两个自由度无法单独变化，使得只有创建36种对象才能完成任务。Bridge模式将继承关系转换为组合关系，从而降低了系统间的耦合，减少了代码编写量，不过但这仅仅是Bridge模式带来的众多好处的一部分。

2.定义

Decouple an abstraction from its implementation,so that the two can vary independently(将抽象和实现解耦，使得两者可以独立地变化。)

Abstraction抽象化角色:它的主要职责是定义出该角色的行为，同时保存一个对实现化角色的引用，该角色一般是抽象类。

RefinedAbstraction修改抽象化角色:它引用实现化角色对抽象化角色进行修正。

Implementor实现化角色:它是接口或者抽象类，定义角色必须的行为和属性。

ConcreteImplementor具体实现化角色:它实现接口或抽象类定义的方法和属性。

3.通用源码

namespace ConsoleApplication1
{
    /// <summary>
    /// 实现化角色
    /// </summary>
    public interface IImplementor
    {
        void DoSomeThing();

        void DoAnyThing();
    }

    /// <summary>
    /// 具体的实现化角色
    /// </summary>
    public class ConcreteImplementor1 : IImplementor
    {
        public void DoSomeThing()
        {
            throw new NotImplementedException();
        }

        public void DoAnyThing()
        {
            throw new NotImplementedException();
        }
    }

    /// <summary>
    /// 具体的实现化角色
    /// </summary>
    public class ConcreteImplementor2 : IImplementor
    {
        public void DoSomeThing()
        {
            throw new NotImplementedException();
        }

        public void DoAnyThing()
        {
            throw new NotImplementedException();
        }
    }

    /// <summary>
    /// 抽象化角色
    /// </summary>
    public abstract class Abstraction
    {
        private readonly IImplementor _implementor;

        protected Abstraction(IImplementor implementor)
        {
            _implementor = implementor;
        }

        protected IImplementor GetImplementor()
        {
            return _implementor;
        }

        public abstract void Request();
    }

    /// <summary>
    /// 具体的抽象化角色
    /// </summary>
    public class ConcreteAbstraction1 : Abstraction
    {
        public ConcreteAbstraction1(IImplementor implementor)
            : base(implementor)
        {
        }

        public override void Request()
        {
            base.GetImplementor().DoSomeThing();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            //定义一个具体的实现类角色
            IImplementor implementor = new ConcreteImplementor1();

            //定义一个具体的抽象类角色
            Abstraction abstraction = new ConcreteAbstraction1(implementor);

            abstraction.Request();

            Console.ReadKey();
        }
    }
}

5.注意事项

(1)效果及实现要点

.Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。

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

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

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

(2)使用场景

.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。

.设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。

.一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。

.虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。

引用

1.设计模式之禅

2.TerryLee 桥接模式

3.蜡笔与毛笔的故事