设计模式(六)桥连模式Bridge(结构型)

设计模式(六)桥连模式Bridge(结构型

1. 概述

      在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?

例子1:设想如果要绘制矩形、圆形、椭圆、正方形,我们至少需要4个形状类,但是如果绘制的图形需要具有不同的颜色,如红色、绿色、蓝色等,此时至少有如下两种设计方案:

•第一种设计方案是为每一种形状都提供一套各种颜色的版本。

•第二种设计方案是根据实际需要对形状和颜色进行组合。 

方案1:

方案2:


      对于有两个变化维度(即两个变化的原因)的系统,采用方案二来进行设计系统中类的个数更少,且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量。

例子2:一个普通的开关控制的电灯、电风扇等等,都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关,也可以是调光开关。

2. 问题

      如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?

3. 解决方案

桥连模式将抽象部分与实现部分分离,使它们都可以独立的变化。它是一种结构性模式,又称柄体(Handle
and body)模式
或者接口(Interface)模式。        当一个抽象可能有多个实现时,通常用继承来协调他们。抽象类的定义对该抽象的接口。而具体的子类则用不同的方式加以实现,但是此方法有时不够灵活。继承机制将抽象部分与他的视线部分固定在一起,使得难以对抽象部分和实现部分独立地进行修改、扩充和充用。

理解桥接模式,重点需要理解如何将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化。

•抽象化:抽象化就是忽略一些信息,把不同的实体当作同样的实体对待。在面向对象中,将对象的共同性质抽取出来形成类的过程即为抽象化的过程。

•实现化:针对抽象化给出的具体实现,就是实现化,抽象化与实现化是一对互逆的概念,实现化产生的对象比抽象化更具体,是对抽象化事物的进一步具体化的产物。

•脱耦:脱耦就是将抽象化和实现化之间的耦合解脱开,或者说是将它们之间的强关联改换成弱关联,将两个角色之间的继承关系改为关联关系。桥接模式中的所谓脱耦,就是指在一个软件系统的抽象化和实现化之间使用关联关系(组合或者聚合关系)而不是继承关系,从而使两者可以相对独立地变化,这就是桥接模式的用意。 

4. 适用性

1). 你不希望在抽象和他的实现部分之间有一个固定的邦定关系,如在程序的运行时刻实现部分应该可以被选择或者切换。

2). 类的抽象以及他的视像都可以通过生成子类的方法加以扩充。这时bridge模式使你可以对不同的抽象接口

      和实现部分进行组合,并对他们进行扩充。

3). 对一个抽象的实现部分的修改应该对客户不产生影响,即客户的代码不需要重新编译。

4). 你想对客户完全隐藏抽象的实现部分。

5). 你想在多个实现间 共享实现,但同时要求客户并不知道这一点。

5. 结构

6. 构建模式的组成

抽象类(Abstraction):定义抽象类的接口,维护一个指向Implementor类型对象的指针

扩充抽象类(RefinedAbstraction)扩充由Abstraction定义的接口

实现类接口(Implementor)定义实现类的接口,该接口不一定要与
Abstraction的接口完全一致;事实上这两个接口可以完全不同。一般来讲, Implementor接口仅提供基本操作,而 Abstraction则定义了基于这些基本操作的较高层次的操作。

具体实现类(ConcreteImplementor)实现Implementor接口并定义它的具体实现。

7. 效果

Bridge模式有以下一些优点:
1) 分离接口及其实现部分 一个实现未必不变地绑定在一个接口上。抽象类的实现可以在运行时刻进行配置,一个对象甚至可以在运行时刻改变它的实现。将Abstraction与Implementor分离有助于降低对实现部分编译时刻的依赖性,当改变一个实现类时,并不需要重新编译 Abstraction类和它的客户程序。为了保证一个类库的不同版本之间的二进制兼容性,一定要有这个性质。另外,接口与实现分离有助于分层,从而产生更好的结构化系统,系统的高层部分仅需知道Abstraction和Implementor即可。
2) 提高可扩充性 你可以独立地对Abstraction和Implementor层次结构进行扩充。

3 ) 实现细节对客户透明 你可以对客户隐藏实现细节,例如共享 Implementor对象以及相应的引用计数机制(如果有的话) 。

桥接模式的缺点

•桥接模式的引入会增加系统的理解与设计难度,由于聚合关联关系建立在抽象层,要求开发者针对抽象进行设计与编程。

•桥接模式要求正确识别出系统中两个独立变化的维度,因此其使用范围具有一定的局限性。 

8.实现

模拟毛笔:

        现需要提供大中小3种型号的画笔,能够绘制5种不同颜色,如果使用蜡笔,我们需要准备3*5=15支蜡笔,也就是说必须准备15个具体的蜡笔类。而如果使用毛笔的话,只需要3种型号的毛笔,外加5个颜料盒,用3+5=8个类就可以实现15支蜡笔的功能。

       实际上,蜡笔和毛笔的关键一个区别就在于笔和颜色是否能够分离。即将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化"。关键就在于能否脱耦。蜡笔的颜色和蜡笔本身是分不开的,所以就造成必须使用15支色彩、大小各异的蜡笔来绘制图画。而毛笔与颜料能够很好的脱耦,各自独立变化,便简化了操作。在这里,抽象层面的概念是:"毛笔用颜料作画",而在实现时,毛笔有大中小三号,颜料有红绿蓝黑白等5种,于是便可出现3×5种组合。每个参与者(毛笔与颜料)都可以在自己的自由度上随意转换。

         蜡笔由于无法将笔与颜色分离,造成笔与颜色两个自由度无法单独变化,使得只有创建15种对象才能完成任务。

Bridge模式将继承关系转换为组合关系,从而降低了系统间的耦合,减少了代码编写量。

UML如图:

代码实现:

[php] view
plain
 copy

 print?

  1. <?php  
  2.   
  3. /******************************Abstraction **************************/  
  4. /** 
  5.  *  
  6.  * Abstraction抽象类的接口 
  7.  * @author guisu 
  8.  * 
  9.  */  
  10. abstract class BrushPenAbstraction {  
  11.     protected $_implementorColor = null;  
  12.   
  13.     /** 
  14.      *  
  15.      * Enter description here ... 
  16.      * @param Color $color 
  17.      */  
  18.     public function setImplementorColor(ImplementorColor $color) {  
  19.         $this->_implementorColor = $color;  
  20.     }  
  21.     /** 
  22.      *  
  23.      * Enter description here ... 
  24.      */  
  25.     public abstract function operationDraw();  
  26. }  
  27. /******************************RefinedAbstraction **************************/  
  28. /** 
  29.  *  
  30.  * 扩充由Abstraction;大毛笔 
  31.  * @author guisu 
  32.  * 
  33.  */  
  34. class BigBrushPenRefinedAbstraction extends BrushPenAbstraction {  
  35.     public function operationDraw() {  
  36.         echo 'Big and ', $this->_implementorColor->bepaint (), ' drawing';  
  37.     }  
  38. }  
  39. /** 
  40.  *  
  41.  * 扩充由Abstraction;中毛笔 
  42.  * @author guisu 
  43.  * 
  44.  */  
  45. class MiddleBrushPenRefinedAbstraction extends BrushPenAbstraction {  
  46.     public function operationDraw() {  
  47.         echo 'Middle and ', $this->_implementorColor->bepaint (), ' drawing';  
  48.     }  
  49. }  
  50. /** 
  51.  *  
  52.  * 扩充由Abstraction;小毛笔 
  53.  * @author guisu 
  54.  * 
  55.  */  
  56. class SmallBrushPenRefinedAbstraction extends BrushPenAbstraction {  
  57.     public function operationDraw() {  
  58.         echo 'Small and ', $this->_implementorColor->bepaint(), ' drawing';  
  59.     }  
  60. }  
  61.   
  62. /******************************Implementor **************************/  
  63. /** 
  64.  * 实现类接口(Implementor) 
  65.  *  
  66.  * @author mo-87 
  67.  * 
  68.  */  
  69. class ImplementorColor {  
  70.     protected $value;  
  71.   
  72.     /** 
  73.      * 着色 
  74.      *  
  75.      */  
  76.     public  function bepaint(){  
  77.         echo $this->value;  
  78.     }  
  79. }  
  80. /******************************oncrete Implementor **************************/  
  81. class oncreteImplementorRed extends ImplementorColor {  
  82.     public function __construct() {  
  83.         $this->value = "red";  
  84.     }  
  85.     /** 
  86.      * 可以覆盖 
  87.      */  
  88.     public function bepaint() {  
  89.         echo $this->value;  
  90.     }  
  91. }  
  92.   
  93. class oncreteImplementorBlue extends ImplementorColor {  
  94.     public function __construct() {  
  95.         $this->value = "blue";  
  96.     }  
  97. }  
  98.   
  99. class oncreteImplementorGreen extends ImplementorColor {  
  100.     public function __construct() {  
  101.         $this->value = "green";  
  102.     }  
  103. }  
  104.   
  105. class oncreteImplementorWhite extends ImplementorColor {  
  106.     public function __construct() {  
  107.         $this->value = "white";  
  108.     }  
  109. }  
  110.   
  111. class oncreteImplementorBlack extends ImplementorColor {  
  112.     public function __construct() {  
  113.         $this->value = "black";  
  114.     }  
  115. }  
  116. /** 
  117.  *  
  118.  * 客户端程序 
  119.  * @author guisu 
  120.  * 
  121.  */  
  122. class Client {  
  123.     public static function Main() {  
  124.   
  125.         //小笔画红色  
  126.         $objRAbstraction = new SmallBrushPenRefinedAbstraction();  
  127.         $objRAbstraction->setImplementorColor(new oncreteImplementorRed());  
  128.         $objRAbstraction->operationDraw();  
  129.     }  
  130. }  
  131. Client::Main();  

跨平台视频播放器:两个维度的变化,平台和不同格式的视频文件:

9. 桥接模式与其他相关模式

1)抽象工厂(Abstract
Factory
模式可以用来创建和配置一个特定的Bridge模式。

2)Adapter模式
用来帮助无关的类协同工作,它通常在系统设计完成后才会被使用。然而,Bridge模式则是在系统开始时就被使用,它使得抽象接口和实现部分可以独立进行改变。

3)桥接模式与装饰的区别:

装饰模式:

      这两个模式在一定程度上都是为了减少子类的数目,避免出现复杂的继承关系。但是它们解决的方法却各有不同,装饰模式把子类中比基类中多出来的部分放到单独的类里面,以适应新功能增加的需要,当我们把描述新功能的类封装到基类的对象里面时,就得到了所需要的子类对象,这些描述新功能的类通过组合可以实现很多的功能组合
.

桥接模式

       桥接模式则把原来的基类的实现化细节抽象出来,在构造到一个实现化的结构中,然后再把原来的基类改造成一个抽象化的等级结构,这样就可以实现系统在多个维度上的独立变化 。

10. 总结

Bridge模式是一个非常有用的模式,也非常复杂,它很好的符合了开放-封闭原则和优先使用对象,而不是继承这两个面向对象原则。

时间: 2024-10-30 15:19:50

设计模式(六)桥连模式Bridge(结构型)的相关文章

学习php设计模式 php实现桥梁模式(bridge)_php技巧

一.桥梁模式结构图   二.桥梁模式中主要角色 抽象化(Abstraction)角色:定义抽象类的接口并保存一个对实现化对象的引用. 修正抽象化(Refined Abstraction)角色:扩展抽象化角色,改变和修正父类对抽象化的定义. 实现化(Implementor)角色:定义实现类的接口,不给出具体的实现.此接口不一定和抽象化角色的接口定义相同,实际上,这两个接口可以完全不同.实现化角色应当只给出底层操作,而抽象化角色应当只给出基于底层操作的更高一层的操作. 具体实现化(Concrete

.net设计模式实例之桥接模式( Bridge Pattern)

一.桥接模式简介(Brief Introduction) 桥接模式(Bridge Pattern),将抽象部分与它的实现部分分离,使的抽象和实现都可以独立地变化. Decouple an abstraction from its implementation so that the two can vary independently.. 什么是聚合/组合: 聚合(Aggregation),当对象A被加入到对象B中,成为对象B的组成部分时,对象B和对象A之间为聚合关系.聚合是关联关系的一种,是较

Java经典设计模式之七大结构型模式(附实例和详解)

版权声明:本文为博主原创文章,转载注明出处http://blog.csdn.net/u013142781 目录(?)[+] 博主在大三的时候有上过设计模式这一门课,但是当时很多都基本没有听懂,重点是也没有细听,因为觉得没什么卵用,硬是要搞那么复杂干嘛.因此设计模式建议工作半年以上的猿友阅读起来才会理解的比较深刻.当然,你没事做看看也是没有坏处的. 总体来说设计模式分为三大类:创建型模式.结构型模式和行为型模式. 博主的上一篇文章已经提到过创建型模式,此外该文章还有设计模式概况和设计模式的六大原则

.NET设计模式-结构型模式专题总结

--探索设计模式系列之十五 Terrylee,2006年5月 摘要:结构型模式,顾名思义讨论的是类和对象的结构,它采用继承机制来组合接口或实现(类结构型模式),或者通过组合一些对象,从而实现新的功能(对象结构型模式).这些结构型模式,它们在某些方面具有很大的相似性,仔细推敲,侧重点却各有不同.本文试图对这几种结构型模式做一个简单的小结.   主要内容 1.结构型模式概述 2.结构型模式区别与比较 3.对变化的封装   结构型模式概述 结构型模式,顾名思义讨论的是类和对象的结构,它采用继承机制来组

.NET设计模式(15):结构型模式专题总结

主要内容 1.结构型模式概述 2.结构型模式区别与比较 3.对变化的封装 结构型模式概述 结构型模式,顾名思义讨论的是类和对象的结构,它采用继承机制来组合接口或实现(类结构型模式),或者通过组合一些对象,从而实现新的功能(对象结构型模式).这些结构型模式,它们在某些方面具有很大的相似性,仔细推敲,侧重点却各有不同. Adapter模式通过类的继承或者对象的组合侧重于转换已有的接口:Bridge模式通过将抽象和实现相分离,让它们可以分别独立的变化,它强调的是系统沿着多个方向的变化:Decorato

一番话--结构型模式

前面我已经讲过了创建型模式,即:工厂模式,抽象工厂模式,单件模式,原型模式,建造者模式.创建型模式都是为了解决对象创建问题的.也就是说,如果你想避免将来为了创建一个你不曾考虑到的对象类型而发愁,就考虑创建型模式.今天我试着说一下结构型模式.结构型模式是为了解决怎么样组装现有的类,并设计他们的交互方式,从而实现一定的功能目的.同时,结构型模式包容了很多问题,例如扩展性(外观模式,组成模式,代理模式,装饰模式),封装性(适配器模式,桥接模式).另外,flyweight模式为我们提供了一个解决大量对象

设计模式2—结构型模式

结构型模式用来处理类或者对象的组合,主要包含以下7种设计模式: 1. 代理模式(Proxy Pattern)就是为其他对象提供一种代理以控制对这个对象的访问. 2. 装饰者模式(Decorator Pattern)动态的给一个对象添加一些额外的职责.就增加功能来说,此模式比生成子类更为灵活.  3. 适配器模式(Adapter Pattern)是将一个类的接口转换成客户希望的另外一个接口.使得原本由于接口不兼容而不能一起工作的那些类可以一起工作.  4. 组合模式(Composite Patte

设计模式(十一)代理模式Proxy(结构型)

设计模式(十一)代理模式Proxy(结构型)    1.概述        因为某个对象消耗太多资源,而且你的代码并不是每个逻辑路径都需要此对象, 你曾有过延迟创建对象的想法吗 ( if和else就是不同的两条逻辑路径) ? 你有想过限制访问某个对象,也就是说,提供一组方法给普通用户,特别方法给管理员用户?以上两种需求都非常类似,并且都需要解决一个更大的问题:你如何提供一致的接口给某个对象让它可以改变其内部功能,或者是从来不存在的功能? 可以通过引入一个新的对象,来实现对真实对象的操作或者将新的

设计模式(九)外观模式Facade(结构型)

设计模式--外观模式Facade(结构型): 1. 概述      外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性. 例子1:一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计. 2. 问题 为了降低复杂性,常常将系统划分为若干个子系统.但是如何做到各个系统之间的通信和相互依赖关系达到最小呢? 3. 解决