一. 从树谈起
基本上所有人都知道树这个概念。
稍微深究.NET本质的人会懂得，.NET有个对象树。
学习ASP.NET的人肯定会知道，Web上有个控件树。
哪怕是只学习过数据结构应付考试的大学生也会知道Tree这个概念。
二. 把需求扩展成树
举个我们最常用的Photoshop做例子。
在Photoshop中，有许多图形工具，比如星星，比如方形，再比如圆形等等。
在Photoshop中，不用多说，也有很多种颜色供我们选择。
于是就产生了，红色的星星，绿色的星星。红色的方形，绿色的方形等等。
看看所产生的树：
现在是三种图形，三种颜色，于是我们就一共去声明了九个类，当然我们还不算中间过程中的辅助父类。
如果我们现在是18种图形，12种颜色，那么我们就需要写18*12个类，然后加上12个颜色的类和一个总父类，一共我们需要12*18+12+1=229个类。
让我们记住这个数字。
希望大家不要和我抬杠说，我们可以把颜色写成Color然后动态传入。我们这里是假设并不存在Color这个属性，而需要我们自己去实现。
三. 对象爆炸
这个词我已经在两个设计模式中提到了。
在<重温设计模式（一）——享元模式> 中，我就用到了这个词。
当然，这里的爆炸并没有上篇文章中的那么恐怖。
但是追寻完美的我们也应该去改善他。
那就让我们开始想办法。
四. 多继承？
学习C++的我，第一个想到的是多继承。
用多继承描述这个模型再恰当不过了。 声明18个图形的类，然后声明12个颜色的类，然后用具体的图形类去多继承。
让我们看看这个表述图：
错综复杂的线看上去可能有些乱，但是我想大家应该都明白这个意思。
理解倒是容易理解了，可是这个时候我们再来看一下这个类的数量：
颜色12+颜色父类1+图形18+图形父类1+12*18，这个数字似乎比我们之前的那个数字还要大。
也许我会为他辩驳说他牺牲了空间而换取了可读性，但是可怜的C#不支持多继承？
五. 多继承为何被抛弃？
1. 从实际应用讲，B继承A并且重写了方法，C继承A并且重写了方法，那么这个时候D多继承了B和C，那么他究竟是继承B的方法还是C的方法呢？
2. 从面向对象角度讲，每个类只应有一个父类，就像说一个人只能有一个父亲一样。
但是多继承毕竟对我们来说还是比较易用的，他很容易理解，就像段中的颜色和图形一样。
抛弃多继承是从Java开始的，关于历史遗留的多继承问题，他们如何去解决呢？
让我们深入Java阵营内部去探索答案。
六. 深入Java阵营，寻找答案
方法一：用接口来取代继承，这个我不敢兴趣，从前我也知道，我想知道点别的。
方法二：实际上，在我们使用继承时，总有着一个主要继承点和次要继承点。然后我们应该分清主次，然后去继承那个主要继承点，然后用AOP去解决次要继承点的问题。
七. AOP+OOP == Complete OOP
AOP，面向切面编程，也称面向方面编程。大多数的设计模式都是在搞接口和外部之间的关系，而很少去深入类的内部去解决问题。AOP则是解决了这个问题。
举个例子，我们在做项目的时候常常需要去记录日志，那么这个日志常常是水平地分布在各个类中，但是其实这个日志功能与这个类的核心功能并无本质联系，这其实违背了对象的单一职责原则，更重要的使这些代码分散个各个角落，非常不容易维护。
AOP其实就是采用一种“横切”技术，深入对象的内部，然后将那些影响了多个类的功能写入一个模块，然后注入到各个类中。从而实现了功能的分离，这个常常用于日志管理，安全控制等次要继承点。
但是我在网上搜了一下，微软官方并未提供AOP框架技术，而都是些子实现框架，尚无Java的Spring之类广泛使用的标准。
八. 退而求其次
Spring的两个关键词：控制反转，依赖注入。
既然我们无法依赖注入，那么我们就普通注入吧。
废话这么多，让我们来步入正题：桥接模式。先来简单地看下结构图：
讲解之前，让我们先看看桥接模式的意思：将抽象部分与实现部分相分离，使他们都可以相互变化。
九. 代码演化
让我来先讲解一下这个模式的大概思路。
仍然用上面的例子做讲解，按照桥接模式，我们应该把所有可变化的点给抽离出来，然后组合到稳定的部分。先看看代码吧。
class Program
{
static void Main(string[] args)
{
PhotoShop ps = new PhotoShop(new RedColor(),
new Star());
ps.Draw();
}
}
interface IColor { }
class RedColor : IColor { }
class BlueColor : IColor { }
class YellowColor : IColor { }
interface IGraphics { }
class Rectangle:IGraphics { }
class Star:IGraphics { }
class Round : IGraphics { }
class PhotoShop
{
IColor color;
IGraphics graphics;
public PhotoShop(IColor c, IGraphics g)
{
this.color = c;
this.graphics = g;
}
public void Draw()
{
Console.WriteLine(color.GetType().ToString());
Console.WriteLine(graphics.GetType().ToString());
}
}
这个时候的结构图应该是这样的：
这个时候让我们来计算一下类的总数：
12个颜色类+18个图形类+1个我们的图形=31个类。是不是很少呢？
十. 探微而知著，追本而溯源
世间本没有路，走得人多了，也便成了路。
其实世间本没有模式，只是原则总结了，便成了模式。
模式是可以衍生的，而原则是相对稳定的，那就让我们从这个模式中去挖掘原则。
在文章伊始，我们想到的都是什么？面向对象三原则继承多态封装中的第一个：继承。于是引发了对象爆炸。而用组合，解决了这个问题。
还记得一个很老套的面试题，抽象类和接口的区别。
那就让我们从这个面试题谈起：
1. 接口是行为的契约，而抽象类是特征的抽象。一个是can do，一个是is a。
2. 面向对象设计原则说：组合优于继承。
好了，让我们来看第二点，为什么说组合优于继承，而不说组合取代继承呢？
让我们继续向下看。
十一. 精益求精
组合优于继承，而不是组成取代继承。
上面的代码，如果不仅仅要求颜色和形状，还要求更多，那么我就要写很多很多的属性，好麻烦。
而且更重要的是，如果有这样的需求，我现在有12种颜色，然后有3种形状，分别是方形，圆形和星星，有两种笔，分别是铅笔和蜡笔。但是我现在铅笔只对应方形和星星，蜡笔只对应圆形和星星。也就是说不存在圆形铅笔和方形蜡笔。这样的话我的组合不是浪费了么？而且客户很可能组合错呀？
是的，不要一味去考虑组合。再重复一次我很爱说的话：模式是为了变化，不要为了模式而模式，我们只需要抽离出变化点就可以了！
如果这样，那我们就写好稳定的部门，有两种选择：
或者是把颜色的作为父类，这个就是看我们个人的选择了。
这样下来，假设说有很多的类，但是我们只有少数的选择，是不是我们的类更少了呢？
十二. 有一种能力叫做取舍
这句话是我在
这里我想说，桥接模式难并不是难在理解，而是难在应用。难在我们怎么去抽取出这个变化点，而保留住我们稳定点。
这个就是设计人员的取舍能力了！
十三. 举一而反三——工厂还是不工厂
工厂模式，这个我相信大家都在熟悉不过了。
去掉丑陋的if-else，然后用工厂给独立成为类。
应对数据库的变化，用抽象工厂+反射+web.config去搞定不同数据访问层。
应对不同验证方式，用工厂+反射。
这几乎成了Petshop的所有层通用的东西。但是在我们的项目中，真的需要这样么？
首先受if-else，他丑陋在哪里，是因为一旦我们引入了新的逻辑条件，就需要修改源码重新编译。
然后是数据库和验证方式，我想，几乎很少有公司真的去修改数据库和他们所习惯的产品的验证方式。
如果是这样，也就是说这些都是固定的，那么我们还有必要为了模式而模式地去用工厂么？
十四. 桥接总结
桥接模式（Bridge pattrern）:将抽象部分与实现部分向分离，使他们都可以独立变化。