桥梁模式和适配器模式的区别
2014-04-08 21:38
183 查看
很多时候经常容易把桥接模式和适配器模式弄混。那什么时候用桥接,什么时候用适配器呢 ?
共同点:桥接和适配器都是让两个东西配合工作
不同点:出发点不同。
适配器:改变已有的两个接口,让他们相容。
桥接模式:分离抽象化和实现,使两者的接口可以不同,目的是分离。
所以说,如果你拿到两个已有模块,想让他们同时工作,那么你使用的适配器。
如果你还什么都没有,但是想分开实现,那么桥接是一个选择。
桥接是先有桥,才有两端的东西
适配是先有两边的东西,才有适配器
桥接是在桥好了之后,两边的东西还可以变化。
抽象不应该依赖于实现细节,实现细节应该依赖于抽象。
问题在于如果抽象B由于固有的原因,本身并不稳定,也有可能变化,怎么办?
举例来说
假如我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的功能需求变化,比如坦克可能有很多种不同的型号:T50,T75,T90……
对于其中的坦克设计,我们可能很容易设计出来一个Tank的抽象基类,然后各种不同型号的Tank继承自该类;
另外的变化原因
但是PC和手机上的图形绘制、声效、操作等实现完全不同……因此对于各种型号的坦克,都要提供各种不同平台上的坦克实现:
这样的设计会带来很多问题:有很多重复代码,类的结构过于复杂,难以维护,最致命的是引入任何新平台,比如在TV上的Tank游戏,都会让整个类层级结构复杂化。
动机(Motivation)
思考上述问题的症结:事实上由于Tank类型的固有逻辑,使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”,一个变化的维度为“型号的变化”。
如何应对这种“多维度的变化”?如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化,而不引入额外的复杂度?
意图(Intent)
将抽象部分与实现部分分离,使它们都可以独立地变化。
——《设计模式》GoF
桥模式不能只是认为是抽象和实现的分离,它其实并不仅限于此。如下面的例子,两个都是抽象的部分。更确切的理解,应该是将一个事物中多个维度的变化分离。
对于这种在多个维度上都会有变化或扩充需求的项目来说,可以考虑引入桥接模式。或许你会说,不管是什么场景,不管什么模式,都可以是抽象场景的一个子类,但是,如果这样的话,4个场景和3种模式就会产生12个子类,而10个场景5种模式就会有50个子类。一味进行继承并不是什么好方法,桥接模式的思想是把继承转化为组合,把乘法(10*5=50)转化为加法(10+5=15)。
例说Bridge应用
版本一
先写各种不同的坦克型号类T50、T75等继承自Tank,然后再让各种平台的坦克继承自对应型号的类,如PCT50,PCT75继承自T50等。这样设计可能会有很多重复的代码,例PCT50和PCT75。
版本二
因为平台和坦克型号都是变化,所以我们把平台的变化作为属性放到基抽象类中。
平台实现类
下面是整个代码的骨架
Tank的型号,和Tank的平台都继承自各自的抽象类,因此它们的变化都不会影响到对方。而它们之间的关联,我们使用组合的方式,把平台类放到Tank类中作为属性。这再次体现了组合优先于继承的思想。多继承的方法就是版本一的代码,这种方式子类和父类的关系太紧,造成紧耦合。
这就是桥模式,把变化引出了基类Tank,使得Tank仅守与型号的变化。
应用程序
在环境交互中使用的都是抽象类,并且把平台实现隐藏,在应用程序中new平台的方式也可以根据情况用Singleton模式或者Abstract Factory模式等实现。
结构(Structure)
其中imp的地方就是一个组合。Abstraction就是我们之前例子中的Tank,它的子类RefinedAbstraction就是T50等型号。Implementor是TankPlatformImplementation类,ConcreteImplementorA和ConcreteImplementorB分别是PCTankImplementation和MobileTankImplementation。
整个设计模式的关键就是组合的使用。
Bridge模式的几个要点
Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象(Tank的型号)和实现(不同的平台)可以沿着格子的维度来变化。
所谓抽象和实现沿着各自维度的变化,即“子类化”它们(比如不同的Tank型号子类,和不同的平台子类),得到各个子类之后,便可以任意组合它们,从而获得不同平台上的不同型号。
Bridge模式有时候类似于多继承方案,但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
下面是针对上面的例子,多继承接口的一种写法:
这样PCT50既需要写T50的实现,又要写Platform的实现,它把型号和平台的变化都引入了PCT50。这样就把两个本不该扭在一起的事务扭在了一起,这样的设计更加糟糕,而且也违背了类的单一职责原则。
Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。
桥模式并不同于适配器模式,适配器模式其实是一个事后诸葛亮,当发现以前的东西不适用了才去做一个弥补的措施。桥模式相对来说所做的改变比适配器模式早,它可以适用于有两个甚至两个以上维度的变化。
共同点:桥接和适配器都是让两个东西配合工作
不同点:出发点不同。
适配器:改变已有的两个接口,让他们相容。
桥接模式:分离抽象化和实现,使两者的接口可以不同,目的是分离。
所以说,如果你拿到两个已有模块,想让他们同时工作,那么你使用的适配器。
如果你还什么都没有,但是想分开实现,那么桥接是一个选择。
桥接是先有桥,才有两端的东西
适配是先有两边的东西,才有适配器
桥接是在桥好了之后,两边的东西还可以变化。
桥梁模式
抽象与实现抽象不应该依赖于实现细节,实现细节应该依赖于抽象。
问题在于如果抽象B由于固有的原因,本身并不稳定,也有可能变化,怎么办?
举例来说
假如我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的功能需求变化,比如坦克可能有很多种不同的型号:T50,T75,T90……
对于其中的坦克设计,我们可能很容易设计出来一个Tank的抽象基类,然后各种不同型号的Tank继承自该类;
另外的变化原因
但是PC和手机上的图形绘制、声效、操作等实现完全不同……因此对于各种型号的坦克,都要提供各种不同平台上的坦克实现:
这样的设计会带来很多问题:有很多重复代码,类的结构过于复杂,难以维护,最致命的是引入任何新平台,比如在TV上的Tank游戏,都会让整个类层级结构复杂化。
动机(Motivation)
思考上述问题的症结:事实上由于Tank类型的固有逻辑,使得Tank类型具有了两个变化的维度——一个变化的维度为“平台的变化”,一个变化的维度为“型号的变化”。
如何应对这种“多维度的变化”?如何利用面向对象技术来使得Tank类型可以轻松地沿着“平台”和“型号”两个方向变化,而不引入额外的复杂度?
意图(Intent)
将抽象部分与实现部分分离,使它们都可以独立地变化。
——《设计模式》GoF
桥模式不能只是认为是抽象和实现的分离,它其实并不仅限于此。如下面的例子,两个都是抽象的部分。更确切的理解,应该是将一个事物中多个维度的变化分离。
对于这种在多个维度上都会有变化或扩充需求的项目来说,可以考虑引入桥接模式。或许你会说,不管是什么场景,不管什么模式,都可以是抽象场景的一个子类,但是,如果这样的话,4个场景和3种模式就会产生12个子类,而10个场景5种模式就会有50个子类。一味进行继承并不是什么好方法,桥接模式的思想是把继承转化为组合,把乘法(10*5=50)转化为加法(10+5=15)。
例说Bridge应用
版本一
先写各种不同的坦克型号类T50、T75等继承自Tank,然后再让各种平台的坦克继承自对应型号的类,如PCT50,PCT75继承自T50等。这样设计可能会有很多重复的代码,例PCT50和PCT75。
版本二
因为平台和坦克型号都是变化,所以我们把平台的变化作为属性放到基抽象类中。
平台实现类
下面是整个代码的骨架
Tank的型号,和Tank的平台都继承自各自的抽象类,因此它们的变化都不会影响到对方。而它们之间的关联,我们使用组合的方式,把平台类放到Tank类中作为属性。这再次体现了组合优先于继承的思想。多继承的方法就是版本一的代码,这种方式子类和父类的关系太紧,造成紧耦合。
这就是桥模式,把变化引出了基类Tank,使得Tank仅守与型号的变化。
应用程序
在环境交互中使用的都是抽象类,并且把平台实现隐藏,在应用程序中new平台的方式也可以根据情况用Singleton模式或者Abstract Factory模式等实现。
结构(Structure)
其中imp的地方就是一个组合。Abstraction就是我们之前例子中的Tank,它的子类RefinedAbstraction就是T50等型号。Implementor是TankPlatformImplementation类,ConcreteImplementorA和ConcreteImplementorB分别是PCTankImplementation和MobileTankImplementation。
整个设计模式的关键就是组合的使用。
Bridge模式的几个要点
Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象(Tank的型号)和实现(不同的平台)可以沿着格子的维度来变化。
所谓抽象和实现沿着各自维度的变化,即“子类化”它们(比如不同的Tank型号子类,和不同的平台子类),得到各个子类之后,便可以任意组合它们,从而获得不同平台上的不同型号。
Bridge模式有时候类似于多继承方案,但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。
下面是针对上面的例子,多继承接口的一种写法:
这样PCT50既需要写T50的实现,又要写Platform的实现,它把型号和平台的变化都引入了PCT50。这样就把两个本不该扭在一起的事务扭在了一起,这样的设计更加糟糕,而且也违背了类的单一职责原则。
Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。
桥模式并不同于适配器模式,适配器模式其实是一个事后诸葛亮,当发现以前的东西不适用了才去做一个弥补的措施。桥模式相对来说所做的改变比适配器模式早,它可以适用于有两个甚至两个以上维度的变化。
相关文章推荐
- 适配器模式、装饰器模式、代理模式的区别
- 桥接模式和适配器模式的区别
- 桥接模式、适配器模式以及外观模式三者的区别
- 装饰器模式、代理模式、适配器模式和外观模式的联系与区别
- Java经典23种设计模式之结构型模式(三)------附代理模式、适配器模式、外观模式区别
- 代理模式与适配器模式的区别
- 设计模式:适配器模式和代理模式的区别
- 装饰模式与适配器模式的的区别
- 点滴:Java设计模式 装饰模式与适配器模式的的区别
- 桥接模式和适配器模式的区别
- 设计模式之桥梁模式和策略模式的区别
- 适配器模式和装饰者模式的区别
- 代理模式 适配器模式 外观模式 装饰模式 区别 比较
- 设计模式之禅之包装模式群大PK【装饰模式VS适配器模式VS门面模式VS代理模式VS桥梁模式】
- 代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式【读书笔记】设计模式4章:结构型模式
- 模式的秘密-适配器模式和代理模式的区别
- 外观模式和适配器模式的区别
- 桥接模式和适配器模式的区别
- 装饰模式与适配器模式的一句话区别
- 适配器模式、装饰器模式和代理模式的联系和区别