Java设计模式 - Bridge（桥接模式）

1. [转载自:http://www.blogjava.net/qinysong/articles/63024.html]

2. [转载自：http://www.itstudy.net/html/200901/14/20090114094647.htm]

[align=left]一句话[/align]
[align=left]将抽象和行为划分开来,各自独立,但能动态的组合。[/align]
[align=left]结构图[/align]



[align=center]图1 Bridge模式结构图[/align]
[align=left]生活中的例子[/align]
[align=center]比如，一杯咖啡为例,子类实现类为四个：中杯加奶、大杯加奶、中杯不加奶、大杯不加奶。这四个类实际是两个角色的组合：抽象和行为，其中抽象为：中杯和大杯；行为为：加奶不加奶（如加橙汁加苹果汁），这就是Bridge模式。[/align]
[align=left]桥接模式解说[/align]
[align=left]以上面提到的咖啡 为例. 我们原来打算只设计一个接口(抽象类),使用Bridge模式后,我们需要将抽象和行为分开,加奶和不加奶属于行为,我们将它们抽象成一个专门的行为接口.[/align]
[align=left]先看看抽象部分的接口代码:[/align]

public abstract class Coffee { 　　CoffeeImp coffeeImp; 　　public void setCoffeeImp() { 　　　　this.CoffeeImp = CoffeeImpSingleton.getTheCoffeImp(); 　　} 　　public CoffeeImp getCoffeeImp() {return this.CoffeeImp;} 　　public abstract void pourCoffee(); }

[align=left]其中CoffeeImp 是加不加奶的行为接口,看其代码如下:[/align]

public abstract class CoffeeImp { 　　public abstract void pourCoffeeImp(); }

[align=left]现在我们有了两个抽象类,下面我们分别对其进行继承:[/align]

//中杯 public class MediumCoffee : Coffee { 　　public MediumCoffee() {setCoffeeImp();} 　　public void pourCoffee() 　　{ //这里加入了行为，到底是加奶还是加柠檬，由coffeeImp决定 　　　　CoffeeImp coffeeImp = this.getCoffeeImp(); 　　　　//我们以重复次数来说明是冲中杯还是大杯 ,重复2次是中杯 　　　　for (int i = 0; i < 2; i++) 　　　　{ 　　　　　　coffeeImp.pourCoffeeImp(); 　　　　} 　　 　　} } //大杯 public class SuperSizeCoffee : Coffee { 　　public SuperSizeCoffee() {setCoffeeImp();} 　　public void pourCoffee() 　　{ //这里加入了行为，到底是加奶还是加柠檬，由coffeeImp决定 　　　　CoffeeImp coffeeImp = this.getCoffeeImp(); 　　　　//我们以重复次数来说明是冲中杯还是大杯 ,重复5次是大杯 　　　　for (int i = 0; i < 5; i++) 　　　　{ 　　　　　　coffeeImp.pourCoffeeImp(); 　　　　} 　　 　　} }

[align=left]上面分别是中杯和大杯的具体实现.下面再对行为CoffeeImp进行继承:[/align]

//加奶 public class MilkCoffeeImp : CoffeeImp { 　　MilkCoffeeImp() {} 　　public void pourCoffeeImp() 　　{ 　　　　//"加了美味的牛奶" 　　} } //不加奶 public class FragrantCoffeeImp : CoffeeImp { 　　FragrantCoffeeImp() {} 　　public void pourCoffeeImp() 　　{ 　　　　//"什么也没加,清香" 　　} }

Bridge模式的基本框架我们已经搭好了,别忘记定义中还有一句:动态结合,我们现在可以喝到至少四种咖啡:

1.中杯加奶

2.中杯不加奶

3.大杯加奶

4.大杯不加奶
[align=left]看看是如何动态结合的,在使用之前,我们做个准备工作,设计一个单件类(Singleton)用来加载当前的CoffeeImp:[/align]

public class CoffeeImpSingleton { 　　private static CoffeeImp coffeeImp; 　　public CoffeeImpSingleton(CoffeeImp coffeeImpIn) 　　 {this.coffeeImp = coffeeImpIn;} 　　public static CoffeeImp getTheCoffeeImp() 　　{ 　　　　return coffeeImp; 　　} }

[align=left]看看中杯加奶 和大杯加奶 是怎么出来的:[/align]
//拿出牛奶

CoffeeImpSingleton coffeeImpSingleton = new CoffeeImpSingleton(new MilkCoffeeImp());

//中杯加奶

MediumCoffee mediumCoffee = new MediumCoffee();

mediumCoffee.pourCoffee();

//大杯加奶

SuperSizeCoffee superSizeCoffee = new SuperSizeCoffee();

superSizeCoffee.pourCoffee();
[align=left]注意: Bridge模式的执行类如CoffeeImp和Coffee是一对一的关系, 正确创建CoffeeImp是该模式的关键.[/align]
[align=left]为了体现Bridge模式的优点，我们再加一个抽象（小杯）和再加一个行为（加柠檬）[/align]
//小杯


public class SmallCoffee : Coffee




...{




　　public SmallCoffee() ...{setCoffeeImp();}




　　public void pourCoffee()




　　...{


//这里加入了行为，到底是加奶还是加柠檬，由coffeeImp决定


　　　　CoffeeImp coffeeImp = this.getCoffeeImp();


　　　　//重复1次是小杯


　　　　for (int i = 0; i < 1; i++)




　　　　...{


　　　　　　coffeeImp.pourCoffeeImp();


　　　　}


　　}


}

[align=left] [/align]
//加柠檬


public class LemonCoffeeImp : CoffeeImp




...{




　　LemonCoffeeImp() ...{}




　　public void pourCoffeeImp()




　　...{


　　　　//"加柠檬"


　　}


}

//拿出柠檬


CoffeeImpSingleton coffeeImpSingleton = new CoffeeImpSingleton(new LemonCoffeeImp ());

//小杯加柠檬

使用Bridge桥接模式的《杯子加料》的uml图



[align=left] 如果不使用Bridge模式，一般的解决方案是这样的[/align]
[align=left][/align]



[align=left] [/align]
[align=left]效果及实现要点[/align]
[align=left]1．Bridge模式使用“对象间的组合关系”解耦了抽象和行为之间固有的绑定关系，使得抽象和行为可以沿着各自的维度来变化。[/align]
[align=left]2．所谓抽象和行为沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同平台上的不同型号。[/align]
[align=left]3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。[/align]
[align=left]4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。[/align]
[align=left]适用性[/align]
[align=left]在以下的情况下应当使用桥梁模式：[/align]
[align=left]1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。[/align]
[align=left]2．设计要求行为化角色的任何改变不应当影响客户端，或者说行为化角色的改变对客户端是完全透明的。[/align]
[align=left]3．一个构件有多于一个的抽象化角色和行为化角色，系统需要它们之间进行动态耦合。[/align]
[align=left]4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。[/align]
[align=left]总结[/align]
[align=left]Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。目前有一种流行的设计模式，个人认为它来源与Bridge的创意，它就是IoC，它的大名鼎鼎的容器是Spring.[/align]
[align=left] [/align]
[align=left] [/align]
[align=left] [/align]
[align=left] [/align]
[align=left] [/align]
[align=left][转载自/article/5101449.html][/align]
生活中的一个例子:

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

概述:

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

意图:

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

——《设计模式》GOF

结构图:




传统的做法:

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

先看一下类结构图:



代码实现:



1

namespace 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

}

客户端调用:



1

static 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）来做;

先看一下类结构图:





代码实现:



1

namespace 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

}

1

namespace 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）来做(多维度变化);

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

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

代码实现:

1

namespace 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模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。

桥接模式与装饰的区别:

装饰模式:

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

桥接模式：

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

[align=left] [/align]
[align=left] [/align]