设计模式之桥接模式 待续

设计模式之桥接模式

目的：　将抽象部分与实现部分分离，使它们都可以独立的变化。

个人理解：  主要用于当出现多个变化点的时候，将多个变化点（实现）与抽象分离，之后通过将变化点以组合的方法放进抽象类   使得抽象部分与实现部分分离。

情景模拟：

1  有一个游戏 坦克大战。 现在要求在电脑和手机里都去实现这个游戏 请先设计出一个坦克。     这时候一般我们会在电脑和手机中分别去实现不同的类  但是这样没有利用好面向对象可复用的优点！

我们可以如此去做 ：

桥接模式示例：

 现在已知 有不同的平台这一个变化点 ，还有不同的型号的坦克 如T50  T75  T90等  这也是一个变化点  有2个变化点。 

 将 shot()   run()等都有的虚函数放到一个 tank抽象类中，  我们还要设计一个抽象的运行平台抽象类     然后由这个平台抽象类  产生PC平台类 ，MOBIL平台类。   

tank抽象类要有一个平台抽象类的对象  用于接收平台的类型以便产生特定平台下的tank 。     

通过继承tank可以产生不同平台下的 不同类型的tank类如tankT50   tankT75 在这里面做一些与平台无关的操作！    然后重载shot  run等函数    让它们去调用PC平台类  或者MOBIL平台类的shot()   run()    （因为shot run 应该会在不同平台下实现时调用不同的API）      

模式核心： 通过分离2个变化点  遵守了单一职责原则（如果用多继承就违反了此原则 此原则强调一个类只有一个变化点）

重点在于使用了组合    通过在tank抽象类中加入了一个平台抽象类的对象  从而巧妙实现了分离！ 它就是所说的桥

在抽象部分就可以通过这个桥来调用具体实现部分的功能。
  

桥接模式UML类图 ：

桥接模式将实现与抽象分离开来，使得RefinedAbstraction依赖于抽象的实现，这样实现了依赖倒转原则，而不管左边的抽象如何变化，只要实现方法不变，右边的具体实现就不需要修改，而右边的具体实现方法发生变化，只要接口不变，左边的抽象也不需要修改。

说起来，其实桥接模式倒是与抽象工厂模式有点像，可以回忆一下抽象工厂模式，抽象工厂模式也是解决多种因素变化的一种方式，抽象工厂模式中，产品的种类和产品的具体实现都会发生变化，于是将产品的种类抽象出来，将具体的实现隔离开来。

        

最新体会：有一种情况，你事先定义了Abstction类和RefinedAbstraction类，你的代码中直接使用的是RefinedAbstraction类，刚开始RefinedAbstraction是够用的。但后来你希望operation()能在不同的情况下有不同的实现，这时候原有的结构就不够用了，你不可能重新继承一个类，那样所有的地方都必须修改，可以考虑的做法就是继承RefinedAbstraction类，这样的改动就比较少，但这样不是最好的。最好的应该是使用上面的桥接模式，将实现分离出来，这样所有的地方都不需要修改，只要添加它的实现就可以了。

优点

1.将实现抽离出来，再实现抽象，使得对象的具体实现依赖于抽象，满足了依赖倒转原则。

2.将可以共享的变化部分，抽离出来，减少了代码的重复信息。

3.对象的具体实现可以更加灵活，可以满足多个因素变化的要求。

缺点

1.客户必须知道选择哪一种类型的实现。

参考：

http://www.cnblogs.com/cxjchen/p/3156872.html

http://blog.csdn.net/fly_yr/article/details/8574742   这个很好