23种设计模式(6)--Bridge模式

面向对象的设计原则:高内聚、低耦合

软件重构原则:小步快跑------抽取的思想(抽取函数、抽取类、抽取接口);对扩展开放、对修改封闭

设计模式分类如下:

Bridge模式主要是解决多维度问题,什么意思呢?类似于n*m这个公式,n种抽象的接口,m种具体的实现,最多可以有n*m种组合方式。

下面这篇文章对Bridge模式讲解的通俗易懂,于是转了过来。

学习设计模式也有一段时间了,今天就把我整理的一篇课程和大家分享,有不妥之处欢迎指出.

生活中的一个例子:

就拿汽车在路上行驶的来说。即有小汽车又有公共汽车,它们都不但能在市区中的公路上行驶,也能在高速公路上行驶。这你会发现,对于交通工具(汽车)有不同的类型,然而它们所行驶的环境(路)也在变化,在软件系统中就要适应两个方面的变化?怎样实现才能应对这种变化呢?

概述:

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

意图:

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

——《设计模式》GOF

结构图:

传统的做法:

通过类继承的方式来做上面的例子;

先看一下类结构图:

代码实现:

1namespace CarRunOnRoad

2{

3    //路的基类;

4    public  class Road

5    {

6        public virtual void Run()

7        {

8            Console.WriteLine("在路上");

9        }

10    }

11    //高速公路;

12    public class SpeedWay : Road

13    {

14        public override void Run()

15        {

16            Console.WriteLine("高速公路");

17        }

18    }

19    //市区街道;

20    public class Street : Road

21    {

22        public override void Run()

23        {

24            Console.WriteLine("市区街道");

25        }

26    }

27    //小汽车在高速公路上行驶;

28    public class CarOnSpeedWay : SpeedWay

29    {

30        public override void Run()

31        {

32            Console.WriteLine("小汽车在高速公路上行驶");

33        }

34    }

35    //公共汽车在高速公路上行驶;

36    public class BusOnSpeedWay : SpeedWay

37    {

38        public override void Run()

39        {

40            Console.WriteLine("公共汽车在高速公路上行驶");

41        }

42    }

43    //小汽车在市区街道上行驶;

44    public class CarOnStreet : Street

45    {

46        public override void Run()

47        {

48            Console.WriteLine("汽车在街道上行驶");

49        }

50    }

51    //公共汽车在市区街道上行驶;

52    public class BusOnStreet : Street

53    {

54        public override void Run()

55        {

56            Console.WriteLine("公共汽车在街道上行驶");

57        }

58    }

59

60}

客户端调用:

1static void Main(string[] args)

2        {

3            //小汽车在高速公路上行驶

4            CarOnSpeedWay Car = new CarOnSpeedWay();

5            Car.Run();

6

7            Console.WriteLine("===========================");

8

9            //公共汽车在街道上行驶

10            BusOnStreet Bus = new BusOnStreet();

11            Bus.Run();

12

13            Console.Read();

14        }

缺点:

但是我们说这样的设计是脆弱的,仔细分析就可以发现,它还是存在很多问题,首先它在遵循开放-封闭原则的同时,违背了类的单一职责原则,即一个类只有一个引起它变化的原因,而这里引起变化的原因却有两个,即路类型的变化和汽车类型的变化;其次是重复代码会很多,不同的汽车在不同的路上行驶也会有一部分的代码是相同的;再次是类的结构过于复杂,继承关系太多,难于维护,最后最致命的一点是扩展性太差。如果变化沿着汽车的类型和不同的道路两个方向变化,我们会看到这个类的结构会迅速的变庞大。

应用设计模式

桥接模式(Bridge)来做;

先看一下类结构图:

代码实现:

1namespace CarRunOnRoad_Bridge_

2{

3

4    //抽象路

5    public abstract class AbstractRoad

6    {

7        protected AbstractCar car;

8        public AbstractCar Car

9        {

10            set

11            {

12                car = value;

13            }

14        }

15

16        public abstract void Run();

17    }

18

19    //高速公路

20    public class SpeedWay : AbstractRoad

21    {

22        public override void Run()

23        {

24            car.Run();

25            Console.WriteLine("高速公路上行驶");

26        }

27    }

28

29    //市区街道

30    public class Street : AbstractRoad

31    {

32        public override void Run()

33        {

34            car.Run();

35            Console.WriteLine("市区街道上行驶");

36        }

37    }

38}

1namespace CarRunOnRoad_Bridge_

2{

3    //抽象汽车

4    public abstract class AbstractCar

5    {

6        public abstract void Run();

7    }

8

9    //小汽车;

10    public class Car : AbstractCar

11    {

12        public override void Run()

13        {

14            Console.Write("小汽车在");

15        }

16    }

17

18    //公共汽车

19    public class Bus : AbstractCar

20    {

21        public override void Run()

22        {

23            Console.Write("公共汽车在");

24        }

25    }

26}

客户端调用:

1 static void Main(string[] args)

2        {

3            //小汽车在高速公路上行驶;

4            AbstractRoad Road1 = new SpeedWay();

5            Road1.Car = new Car();

6            Road1.Run();

7            Console.WriteLine("=========================");

8

9            //公共汽车在高速公路上行驶;

10            AbstractRoad Road2 = new SpeedWay();

11            Road2.Car = new Bus();

12            Road2.Run();

13

14

15

16            Console.Read();

17        }

可以看到,通过对象组合的方式,Bridge 模式把两个角色之间的继承关系改为了耦合的关系,从而使这两者可以从容自若的各自独立的变化,这也是Bridge模式的本意。

这样增加了客户程序与路与汽车的耦合。其实这样的担心是没有必要的,因为这种耦合性是由于对象的创建所带来的,完全可以用创建型模式去解决。在应用时结合创建型设计模式来处理具体的问题。

应用设计模式:

桥接模式(Bridge)来做(多维度变化);

结合上面的例子,增加一个维度"人",不同的人开着不同的汽车在不同的路上行驶(三个维度);

结合上面增加一个类"人",并重新调用.

代码实现:

1namespace CarRunOnRoad_Bridge_

2{

3    abstract class people

4    {

5        AbstractRoad road;

6        public AbstractRoad Road

7        {

8            get

9            {

10                return road;

11            }

12            set

13            {

14                road = value;

15            }

16        }

17        public abstract void Run();

18

19    }

20    class Man : people

21    {

22        public override void Run()

23        {

24            Console.Write("男人开着");

25            Road.Run();

26        }

27    }

28

29    class WoMan : people

30    {

31        public override void Run()

32        {

33            Console.Write("女人开着");

34            Road.Run();

35        }

36    }

37}

客户端调用:

1 static void Main(string[] args)

2        {

3

4            //男人开着公共汽车在高速公路上行驶;

5            Console.WriteLine("=========================");

6

7            AbstractRoad Road3 = new SpeedWay();

8            Road3.Car = new Bus();

9

10            people p = new Man();

11            p.Road = Road3;

12            p.Run();

13

14            Console.Read();

15        }

效果及实现要点:

1.Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现可以沿着各自的维度来变化。

2.所谓抽象和实现沿着各自维度的变化,即“子类化”它们,得到各个子类之后,便可以任意它们,从而获得不同路上的不同汽车。

3.Bridge模式有时候类似于多继承方案,但是多继承方案往往违背了类的单一职责原则(即一个类只有一个变化的原因),复用性比较差。Bridge模式是比多继承方案更好的解决方法。

4.Bridge模式的应用一般在“两个非常强的变化维度”,有时候即使有两个变化的维度,但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果,并不一定要使用Bridge模式。

适用性:

在以下的情况下应当使用桥梁模式:

1.如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的联系。

2.设计要求实现化角色的任何改变不应当影响客户端,或者说实现化角色的改变对客户端是完全透明的。

3.一个构件有多于一个的抽象化角色和实现化角色,系统需要它们之间进行动态耦合。

4.虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。

总结:

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

桥接模式与装饰的区别:

装饰模式:

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

桥接模式:

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

转: http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html

时间: 2024-11-05 21:50:33

23种设计模式(6)--Bridge模式的相关文章

Java经典23种设计模式之创造型模式(二)

本文记录5种创造型模式的剩下两种:建造者模式(Builder).原型模式(PROTOTYPE). 一.建造者模式(别名:生成者模式) 将复杂对象的构建和它的表示分离,使得同样的构建过程可以创建不同的表示.一个完整的建造者模式包含以下几个概念: 1.产品类 Product public class Person { private String head; private String body; private String foot; public String getHead() { ret

JAVA开发的23种设计模式之 --- 桥接模式

桥接模式 概述:将抽象部分与他的实现部分分离,这样抽象化与实现化解耦,使他们可以独立的变化.如何实现解耦的呢,就是通过提供抽象化和实现化之间的桥接结构.    应用场景        实现系统可能有多个角度分类,每一种角度都可能变化.    解释:桥接模式将继承模式转化成关联关系,他降低了类与类之间的耦合度,减少了系统中类的数量,也减少了代码量.    理解抽象化,实现化,解耦        抽象化:将复杂物体的一个或几个共同的特性抽出去而只注意其他特性的行动或过程.在java面向对象中抽象化就

Java经典23种设计模式之创造型模式(一)

设计模式被称为程序猿的内功,之前零零散散的看过一大部分,但自己么有总结过.故此次在这里总结下.值得一提的是,设计模式并不是Java所特有.由于一直搞Android.这里就用Java为载体.最经典的设计模式有23种,分三个大类型: 创建型模式(5) .结构型模式(7).行为型模式(11),5 + 7 +11 = 23.网上一搜也都是一大把了,这里不过个人作的记录.本文记录创造型模式里的工厂方法(Factory Method).抽象工厂(Abstract Factory).单例模式这三种.力求透彻.

23种设计模式(19)---Command模式

命令(Command)模式属于对象的行为模式[GOF95].命令模式又称为行动(Action)模式或交易(Transaction)模式.命令模式把一个请求或者操作封装到一个对象中.命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能. 命令模式是对命令的封装.命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象. 每一个命令都是一个操作:请求的一方发出请求要求执行一个操作:接收的一方收到请求,并执行操作.命令模式允许请求的一方和接收的

23种设计模式之代理模式(Proxy)

代理模式是一种对象结构型模式,可为某个对象提供一个代理,并由代理对象控制对原对象的引用.代理模式能够协调调用者和被调用者,能够在一定程度上降低系统的耦合度,其缺点是请求的处理速度会变慢,并且实现代理模式需要额外的工作. 优点: 1)远程代理可以隐藏对象位于不同的地址空间的事实. 2)虚拟代理可以执行优化操作,例如根据需要创建一个对象. 使用场景:需要比简单的指针更灵活.更全面的对象引用. Proxy 模式

23种设计模式之原型模式(Prototype)

在系统开发过程中,有时候有些对象需要被频繁创建,原型模式通过给出一个原型对象来指明所要创建的对象的类型,然后通过复制这个原型对象的办法,创建出更多同类型的对象.原型模式是一种对象创建型模式,用原型实例制定创建对象的种类,并且通过复制这些原型创建新的对象.原型模式又可分为两种:浅克隆和深克隆.浅克隆仅仅复制所考虑的对象,而不复制它所引用的对象,也就是其中的成员对象并不复制:深克隆除了对象本身被复制外,对象包含的引用也被复制,即成员对象也被复制. 优点: 1)可以在运行时添加或删除产品. 2)通过改

【Unity与23种设计模式】解释器模式(Interpreter)

GoF中定义: "定义一个程序设计语言所需要的语句,并提供解释来解析(执行)该语言." 传统上,执行程序代码通常通过两种方式 第一种:编译程序 第二种:解释器 常见的使用解释器的程序设计语言 包含流行与网页设计领域中的脚本语言 如JavaScript.PHP.Ruby等 这些程序代码经过一般文本编辑器编写完成后放入指定的位置 就可以由应用程序中的解释器直接执行 包括Lua Unity中 编写好的脚本程序执行之前会被UnityEngine编译过 严格来说不算是解释器模式 但与十几年前的开

[23种设计模式]---装饰者模式(1)

装饰者官方说: 装饰模式(Decorator Pattern),也称为包装模式(Wrapper Pattern)指的是在不必改变原类文件和使用继承的情况下,动态地扩展一个对象的功能.它是通过创建一个包装对象,也就是装饰来包裹真实的对象. 咱这么说: 比如说,我要设计一个咖啡厅订单管理项目, 订单肯定包括 咖啡的种类和一些配料,如果我设计一个抽象类,让所有这些东西都去继承他,那肯定会引起类爆炸,自己以后想往里添加新的咖啡类型和配料,你都有可能找不到,影响拓展性,不方便改动和维护,就行这样,多麻烦,

【Unity与23种设计模式】备忘录模式(Memento)

GoF中定义: "在不违反封装的原则下,获取一个对象的内部状态并保留在外部,让对象可以在日后恢复到原先保留时的状态." 对于一些需要存储的数据,比如历史最高分 当与得分减分系统写入一个类时,违反了单一职责原则 最好是做一个SaveData的类单独存储或获取 而当使用一个单独的类时,又必须将数据public向外公开 这就将游戏置于危险的境地,甚至是方便了外挂横行 针对此矛盾局势 备忘录模式便解决了这一问题 备忘录模式可以描述为: 在不增加各个游戏系统类成员的"存取"方