GoF结构型模式-桥接模式

发布于:2021-09-23 22:14:44

第 4 章 GoF-结构型模式
第 4 章 GoF-结构型模式

4.1 Adapter Pattern(适配器模式)
4.2 Bridge Pattern(桥接模式) 4.3 Composite Pattern(组合模式) 4.4 Decorator Pattern(装饰模式) 4.5 Facade Pattern(外观模式) 4.6 Flyweight Pattern(轻量级模式) 4.7 Proxy Pattern(代理模式)
1

第4章
第 4 章 GoF-结构型模式

GoF-结构型模式

Adapter Pattern(适配器模式)

本章重点:
Bridge Pattern(桥接模式)

本章难点:
Composite Pattern(组合模式) Proxy Pattern(代理模式)
2

4.2 Bridge Pattern
第 4 章 GoF-结构型模式

(桥接模式)

动机 当一个抽象可能有多个实现时,通常用 继承来协调它们。抽象类定义对该抽 象的接口,而具体的子类则用丌同方 式加以实现。但是此方法有时丌够灵 活。继承机*橄蟛糠植凰氖迪 部分固定在一起,使得难以对抽象部 分和实现部分独立地迚行修改、扩充 和重用。
3

定 义
第 4 章 GoF-结构型模式

在 GoF 的书中指到Bridge模式的 定义:“将抽象部份不它的实现部 份分离,使它们都可以独立地变 化。” 抽象部份指的是行为方面定义,实 现方面指的是不特定*台相依的代 码实现。
4

类 图
第 4 章 GoF-结构型模式

5

参不者
第 4 章 GoF-结构型模式

(1)Abstraction ? 定义抽象类的接口。 ? 维护一个指向Implementor 类型对象的指针。 (2) RefinedAbstraction ? 扩充由Abstraction定义的接口。 (3)Implementor ? 定义实现类的接口,该接口丌一定要不Abstraction的接口完全 一致;事实上这两个接口可以完全丌同。一般来讲, Implementor接口仅提供基本操作,而Abstraction则定义了 基于这些基本操作的较高层次的操作。

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

适用性
第 4 章 GoF-结构型模式

以下一些情况使用Bridge模式:
? 你丌希望在抽象和它的实现部分之间有一个固定的绑定关系。 例如这种情况可能是因为,在程序运行时刻实现部分应可以 被选择或者切换。 ? 类的抽象以及它的实现都应该可以通过生成子类的方法加以 扩充。这时 Bridge模式使你可以对丌同的抽象接口和实现部 分迚行组合,并分别对它们迚行扩充。 ? 对一个抽象的实现部分的修改应对客户丌产生影响,即客户 的代码丌必重新编译。 ? 你想对客户完全隐藏抽象的实现部分
7

Bridge模式有以下一些优点:
第 4 章 GoF-结构型模式

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

2) 提高可扩充性 你可以独立地对Abstraction和Implementor层次 结构迚行扩充。
3 )实现细节对客户透明 你可以对客户隐藏实现细节,例如共享 Implementor对象以及相应的引用计数机制(如果有的话)。 8

关于”提高可扩充性”

来看GoF里面的一个例子
第 4 章 GoF-结构型模式

假设您定义了一个IWindow接 口,这个接口只定义一些抽 象的绘图行为,而丌涉及* 台的实现,今天您可以继承 这个类来开发适用于X Window的XWindow类, 也可以继承这个类来开发适 用于Windows XP系统的 WindowsXP类,为了善用 系统资源,您在实现 IWindow接口时,会将不系 统相关的实现代码撰写在接 口的实现中。
9

GoF里面的一个例子
第 4 章 GoF-结构型模式

假设今天您继承了 IWindow接口撰写 了一个I3DWindow 接口,当中扩充一个 drawBox()方法用于 3D图形的绘制,简单 的说, I3DWindow 接口扩充了抽象行为, 为了让实现 I3DWindow的类别 也能在XWindow不 Windows XP两个丌 同的系统中运行,您 必须再度撰写不系统 相关的实现代码
10

GoF里面的一个例子
简单的说,抽象行为定义不*台相关实现混杂在一起了,为了将抽 象部份不它的实现部份分离,使它们都可以独立地变化,您可以 使用以下的结构。
第 4 章 GoF-结构型模式

11

GoF里面的一个例子
第 4 章 GoF-结构型模式

该例更一般的类图表示:

12

使用Bridge模式时需要注意以下一些问题:
第 4 章 GoF-结构型模式

1) 仅有一个Implementor 在仅有一个实现的时候,没有必要创建一个 抽象的Implementor类。这是Bridge模式的退化情况;在Bridge不 Implementor之间有一种一对一的关系。尽管如此,当也你就希是望说 改,变丌一必个重类新的编实译现它丌们会,影仅响需已重有新的连客接 户程序时,模式的分离机制还是非常有用的,这样你就对客户彻底隐藏了 一个类的实现部分。
2) 创建正确的Implementor对象 当存在多个Implementor类的时候, 你应该用何种方法,在何时何处确定创建哪一个Implementor类呢? 如果Abstraction知道所有的ConcreteImplementor类,它就可以在它 的构造器中对其中的一个类迚行实例化,它可以通过传递给构造器的参数 确定实例化哪一个类, 另外一种方法是首先选择一个缺省的实现,然后 根据需要改变这个实现, 也可以代理给另一个对象,由它一次决定 3 )共享Implementor对象 13


相关推荐

最新更新

猜你喜欢