类关系图
7in10笔记:泡妞之桥梁模式

类角色说明
·抽象化(Abstraction)角色:抽象化给出的定义,并保存一个对实现化对象的引用。
·修正抽象化(Refined Abstraction)角色:扩展抽象化角色,改变和修正父类对抽象化的定义。
·实现化(Implementor)角色:这个角色给出实现化角色的接口,但不给出具体的实现。必须指出的是,这个接口不一定和抽象化角色的接口定义相同,实际上,这两个接口可以非常不一样。实现化角色应当只给出底层操作,而抽象化角色应当只给出基于底层操作的更高一层的操作。
·具体实现化(Concrete Implementor)角色:这个角色给出实现化角色接口的具体实现。

意图
将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化。

适用性
·如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的联系。
·设计要求实现化角色的任何改变不应当影响客户端,或者说实现化角色的改变对客户端是完全透明的。
·一个构件有多于一个的抽象化角色和实现化角色,系统需要它们之间进行动态耦合。
·虽然在系统中使用继承是没有问题的,但是由于抽象化角色和具体化角色需要独立变化,设计要求需要独立管理这两者。

泡妞的例子
BRIDGE —早上碰到MM,要说早上好,晚上碰到MM,要说晚上好;碰到MM穿了件新衣服,要说你的衣服好漂亮哦,碰到MM新做的发型,要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题,自己用BRIDGE组合一下不就行了。

泡妞的代码
7in10笔记:泡妞之桥梁模式using System;
7in10笔记:泡妞之桥梁模式
using System.Collections;
7in10笔记:泡妞之桥梁模式
7in10笔记:泡妞之桥梁模式
//"Implementor"实现化
7in10笔记:泡妞之桥梁模式
public abstract class MM
}


桥梁模式
将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以独立的变化。

说明
其实我感觉这个例子不是很能说明问题,看了一些网络上的解释,感觉吕老师的毛笔例子比较有说服力,如果这个例子看不明白,可以看看吕老师的例子:http://www.cnblogs.com/zhenyulu/articles/67016.html

相关文章:

  • 2021-10-23
  • 2021-10-29
  • 2021-08-24
  • 2021-08-31
  • 2021-12-13
猜你喜欢
  • 2021-06-12
  • 2021-06-24
相关资源
相似解决方案