设计模式 之桥梁模式
一不是想重复书上的例子,二也不想写别人写过的例子....
搞的自己很烦躁,烦躁的是不知道到底有没有搞懂模式,如果说搞懂了，至少能够应用吧....
可是,我连一个好点的例子都找不到.....
没办法,先记下一些吧......
概述
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图
将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》]
前言:
设计模式原则中,有一个原则,叫 依赖倒转原则..讲的是应该依赖抽象,而不是依赖具体的实现.....
在所有的创建型模式里面，经常的可以用到这原则.(郁闷,好不容易画了个uml图,结果不知道怎么上传....)
及 我们经常的在 一个类A中,保存一个抽象类B或者接口B 的引用.......对于B的实现类来说,不管他们有多少的变化,对类A 来说,都没什么影响.....
可是,如果说类A也要变化,这样怎么办呢?
一般说，如果类还有要变化的因素,那就继承咯....
可是， 按照类的单一性原来来说...引起类A变化的原因,应该只有一个...
所以,我们有必要用一种方法来从新设计这个类....
还是使用依赖倒转原则来实现吧....
如果说,类A 有两个方面或者多纬度的方向的改变原因,我们足可以抽象出一个接口,由接口保存着对某一可变原因的引用.....(吗的，很烦躁..好不容易用visio来画了个uml图,结果拷贝不过来......)
例子先省略....
(以下是 摘抄别人的文章........)
效果及实现要点
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。
适用性
在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
总结
Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。