设计模式--桥接模式Bridge(结构型)
2016-12-28 15:00
519 查看
一、概述
在软件系统中,某些类型由于自身的逻辑,它具有两个或者多个维度的变化,如何应对这种“多维度的变化”,就可以利用桥接模式。
引例:
设想如果要绘制矩形、圆形、椭圆、正方形,我们至少需要4个形状类,但是如果绘制的图形需要具有不同的颜色,如红色、绿色、蓝色等,此时至少有如下两种设计方案:
•第一种设计方案是为每一种形状都提供一套各种颜色的版本。
•第二种设计方案是根据实际需要对形状和颜色进行组合。
对于有两个变化维度(即两个变化的原因)的系统,采用方案二来进行设计系统中类的个数更少,且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量。
二、UML图
抽象类(Abstraction):定义抽象类的接口,维护一个指向Implementor类型对象的指针
扩充抽象类(RefinedAbstraction):扩充由Abstraction定义的接口
实现类接口(Implementor):定义实现类的接口,该接口不一定要与
Abstraction的接口完全一致;事实上这两个接口可以完全不同。一般来讲, Implementor接口仅提供基本操作,而 Abstraction则定义了基于这些基本操作的较高层次的操作。
具体实现类(ConcreteImplementor):实现Implementor接口并定义它的具体实现。
三、例子
拿汽车在路上行驶的来说。即有小汽车又有公共汽车,它们都不但能在市区中的公路上行驶,也能在高速公路上行驶。这你会发现,对于交通工具(汽车)有不同的类型,然而它们所行驶的环境(路)也在变化,在软件系统中就要适应两个方面的变化?怎样实现才能应对这种变化呢?
传统做法:
这种设计存在很多问题,首先它在遵循开放-封闭原则的同时,违背了类的单一职责原则,即一个类只有一个引起它变化的原因,而这里引起变化的原因却有两个,即路类型的变化和汽车类型的变化;其次是重复代码会很多,不同的汽车在不同的路上行驶也会有一部分的代码是相同的;再次是类的结构过于复杂,继承关系太多,难于维护,最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化,我们会看到这个类的结构会迅速的变庞大。
采用桥接模式
参考:
http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html
http://blog.csdn.net/hguisu/article/details/7529194
在软件系统中,某些类型由于自身的逻辑,它具有两个或者多个维度的变化,如何应对这种“多维度的变化”,就可以利用桥接模式。
引例:
设想如果要绘制矩形、圆形、椭圆、正方形,我们至少需要4个形状类,但是如果绘制的图形需要具有不同的颜色,如红色、绿色、蓝色等,此时至少有如下两种设计方案:
•第一种设计方案是为每一种形状都提供一套各种颜色的版本。
•第二种设计方案是根据实际需要对形状和颜色进行组合。
对于有两个变化维度(即两个变化的原因)的系统,采用方案二来进行设计系统中类的个数更少,且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量。
二、UML图
抽象类(Abstraction):定义抽象类的接口,维护一个指向Implementor类型对象的指针
扩充抽象类(RefinedAbstraction):扩充由Abstraction定义的接口
实现类接口(Implementor):定义实现类的接口,该接口不一定要与
Abstraction的接口完全一致;事实上这两个接口可以完全不同。一般来讲, Implementor接口仅提供基本操作,而 Abstraction则定义了基于这些基本操作的较高层次的操作。
具体实现类(ConcreteImplementor):实现Implementor接口并定义它的具体实现。
三、例子
拿汽车在路上行驶的来说。即有小汽车又有公共汽车,它们都不但能在市区中的公路上行驶,也能在高速公路上行驶。这你会发现,对于交通工具(汽车)有不同的类型,然而它们所行驶的环境(路)也在变化,在软件系统中就要适应两个方面的变化?怎样实现才能应对这种变化呢?
传统做法:
namespace CarRunOnRoad { //路的基类; public class Road { public virtual void Run() { Console.WriteLine("在路上"); } } //高速公路; public class SpeedWay : Road { public override void Run() { Console.WriteLine("高速公路"); } } //市区街道; public class Street : Road { public override void Run() { Console.WriteLine("市区街道"); } } //小汽车在高速公路上行驶; public class CarOnSpeedWay : SpeedWay { public override void Run() { Console.WriteLine("小汽车在高速公路上行驶"); } } //公共汽车在高速公路上行驶; public class BusOnSpeedWay : SpeedWay { public override void Run() { Console.WriteLine("公共汽车在高速公路上行驶"); } } //小汽车在市区街道上行驶; public class CarOnStreet : Street { public override void Run() { Console.WriteLine("汽车在街道上行驶"); } } //公共汽车在市区街道上行驶; public class BusOnStreet : Street { public override void Run() { Console.WriteLine("公共汽车在街道上行驶"); } } } static void Main(string[] args) { //小汽车在高速公路上行驶 CarOnSpeedWay Car = new CarOnSpeedWay(); Car.Run(); Console.WriteLine("==========================="); //公共汽车在街道上行驶 BusOnStreet Bus = new BusOnStreet(); Bus.Run(); Console.Read(); }
这种设计存在很多问题,首先它在遵循开放-封闭原则的同时,违背了类的单一职责原则,即一个类只有一个引起它变化的原因,而这里引起变化的原因却有两个,即路类型的变化和汽车类型的变化;其次是重复代码会很多,不同的汽车在不同的路上行驶也会有一部分的代码是相同的;再次是类的结构过于复杂,继承关系太多,难于维护,最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化,我们会看到这个类的结构会迅速的变庞大。
采用桥接模式
namespace CarRunOnRoad_Bridge_ { //抽象路 public abstract class AbstractRoad { protected AbstractCar car; public AbstractCar Car { set { car = value; } } public abstract void Run(); } //高速公路 public class SpeedWay : AbstractRoad { public override void Run() { car.Run(); Console.WriteLine("高速公路上行驶"); } } //市区街道 public class Street : AbstractRoad { public override void Run() { car.Run(); Console.WriteLine("市区街道上行驶"); } } } namespace CarRunOnRoad_Bridge_ { //抽象汽车 public abstract class AbstractCar { public abstract void Run(); } //小汽车; public class Car : AbstractCar { public override void Run() { Console.Write("小汽车在"); } } //公共汽车 public class Bus : AbstractCar { public override void Run() { Console.Write("公共汽车在"); } } } static void Main(string[] args) { //小汽车在高速公路上行驶; AbstractRoad Road1 = new SpeedWay(); Road1.Car = new Car(); Road1.Run(); Console.WriteLine("========================="); //公共汽车在高速公路上行驶; AbstractRoad Road2 = new SpeedWay(); Road2.Car = new Bus(); Road2.Run(); Console.Read(); }
参考:
http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html
http://blog.csdn.net/hguisu/article/details/7529194
相关文章推荐
- 【设计模式基础】结构型模式 - 4 - 桥接(Bridge)
- 设计模式(7)-结构型-桥接模式(Bridge)(个人笔记)
- 设计模式(3)-结构型-桥接模式(Bridge)
- 设计模式-结构型- 桥接模式(Bridge)
- [导入]C#面向对象设计模式纵横谈(8):Bridge 桥接模式(结构型模式).zip(9.01 MB)
- 设计模式笔记--结构型模式之二--桥接 Bridge
- 设计模式(八):Bridge桥接模式 -- 结构型模式
- 【结构型模式】桥接模式(Bridge)之23种java设计模式
- 结构型设计模式之桥接模式(Bridge Pattern)
- 设计模式之结构型模式(一)-----桥接(bridge)模式
- [设计模式-结构型]桥接(Bridge )
- Bridge桥接(结构型模式)——读李建忠设计模式
- C#面向对象设计模式学习笔记(7) - Bridge 桥接模式(结构型模式)
- [设计模式-结构型]桥接(Bridge )
- 【设计模式】结构型模式之桥接Bridge
- 设计模式学习之桥接模式(Bridge,结构型模式)(15)
- 【设计模式学习笔记八】【结构型模式】【桥接模式(Bridge)】
- 设计模式--桥接模式Bridge(结构型)
- Java经典设计模式-结构型模式-桥接模式(Bridge)
- 设计模式之八:Bridge(桥接)—对象结构型模式