设计模式2

Bridge模式
四人帮的说法“将抽象部分和它的实现部分分离，使他们可以独立地变化”
理解起来就是，有个模块A，能够把它分割成2个独立的概念，一个是它的抽象部分，一个是它的具体实现部分，这2个部分可以独立的改变。就是说如果有了新的实现算法，抽象部分可以不用感知到这种变化，这也是抽象部分就不需要改变；反过来，抽象部分有了变化，对于实现部分也不用去关心这种变化，从而实现部分也不需要变化。
具体例子来说：
有个模块A用于显示，它可以画正方形Rectangle，也可以画圆Circle；同是画的算法有2套（V1Drawing和V2Drawing），最简单的实现模型如下：

       基类 Shape，包含一个draw（）的方法，从Shape中继承出来 Rectangle类和 Circle类。由于有2套算法，于是在从 Rectangle类中继承出V1Rectangle类和V2 Rectangle类，同是从Circle类中继承出V1Circle类和V2Circle类。统计起来，2个对象，2套算法，一共有4个具体类。如果对象有变化了，还要添加一个五角星的显示，那么3个对象，2套算法，一共6个具体类。如果又有一套新的算法V3Drawing，。。。。。。。。。。总之，具体类将会变成很多很多。
       这时候，Bridge模式有用了。抽象部分和实现部分分离。上面的例子，shape就是抽象部分，算法drawing就是实现部分，如果我们把这2个部分分离：
     Shape        ---> 继承出 Rectangle类 和 Circle类。
     Drawing   --->继承出 V1Drawing类和V2Drawing类。
他们如何发生关系呢？使用组合（类设计中也有一条原则，优先使用组合而不是继承），即，Shape类中有个成员变量就是Drawing对象的指针。shape的子类通过调用Drawing对象的draw（）方法来实现shape的显示功能。

   通过这种改变后，如果shape添加了一个五角星类，drawing完全不用关心。同样的drawing如果有个新的之类V3Drawing类，对于shape也是不用关心。2个部分可以独立的进行变化。这就是Bridge模式。