设计模式学习笔记--桥梁(Bridge)模式


写在模式学习之前


       什么是设计模式:在我们进行程序设计时,逐渐形成了一些典型问题和问题的解决方案,这就是软件模式;每一个模式描述了一个在我们程序设计中经常发生的问题,以及该问题的解决方案;当我们碰到模式所描述的问题,就可以直接用相应的解决方法去解决这个问题,这就是设计模式。

       设计模式就是抽象出来的东西,它不是学出来的,是用出来的;或许你根本不知道任何模式,不考虑任何模式,却写着最优秀的代码,即使以“模式专家”的角度来看,都是最佳的设计,不得不说是“最佳的模式实践”,这是因为你积累了很多的实践经验,知道“在什么场合代码应该怎么写”,这本身就是设计模式。

       有人说:“水平没到,学也白学,水平到了,无师自通”。诚然,模式背熟,依然可能写不出好代码,更别说设计出好框架;OOP理解及实践经验到达一定水平,同时也意味着总结了很多好的设计经验,但"无师自通",却也未必尽然,或者可以说,恰恰是在水平和经验的基础上,到了该系统的学习一下“模式”的时候了,学习一下专家总结的结果,印证一下自己的不足,对于提高水平还是很有帮助的。

       本系列的设计模式学习笔记,实际是对于《Java与模式》这本书的学习记录。


桥梁模式的定义


桥梁模式的用意是“将抽象化(Abstraction)与实现化(Implementation)解耦,使得二者可以独立地变化”。

强关联和弱关联:

所谓强关联,就是在编译期已经确定的,无法在运行期动态改变的关联;所谓弱关联,就是可以动态地确定并且可以在运行期动态地改变的关联。

继承是强关联,而聚合关系是弱关联。

桥梁模式是为了解决“继承”灵活性不够的问题,提供了这样一种用聚合关系实现的弱耦合解决方案。

桥梁模式又称为柄体(Handle and Body)模式或接口(Interface)模式。


桥梁模式的结构


结构图


设计模式学习笔记--桥梁(Bridge)模式_第1张图片

由上图可以看出,桥梁模式有两个等级结构:

(1)左侧的由抽象化角色和修正抽象化角色组成的抽象化等级结构。

(2)由实现化角色和两个具体实现化角色所组成的实现化等级结构。


所涉及的角色


(1)抽象化(Abstraction)角色:抽象化给出的定义,并保存一个对实现化对象的引用。

(2)修正抽象化(Refined Abstraction)角色:扩展抽象化角色,改变和修正父类对抽象化的定义。

(3)实现化(Implementor)角色:这个角色给出实现化角色的接口,但不给出具体的实现。必须指出的是,这个接口不一定和抽象化角色的接口定义相同,实际上,这两个接口可以非常不一样。实现化角色应该只给出底层操作,而抽象化角色应该只给出基于底层操作的更高一层的操作。

(4)具体实现化(Concrete Implementor)角色:这个角色给出实现化角色接口的具体实现。

抽象化角色就像是一个水杯的手柄,而实现化角色和具体实现化角色就像是水杯的杯身,这也就是此模式别名“柄体”的来源。


代码实现


abstract class Abstraction
{
	protected Implementor imp;
	public void operation()
	{
		imp.operationImp();
	}
}
class RefinedAbstraction extends Abstraction
{
	public void operation()
	{
		//improved logic
	}
}
abstract class Implementor
{
	public abstract void operationImp();
}
class ConcreteImplementorA extends Implementor
{
	public void operationImp()
	{
		System.out.println("Do something...");
	}
}

对变化的封装


找到系统的可变因素,将之封装起来,通常就叫做“对变化的封装”。对变化的封装实际上是达到“开-闭”原则的途径,与组合/聚合复用原则是相辅相成的。

桥梁模式是“对变化的封装”原则以及组合/聚合复用原则的极好例子。


一个基于桥梁模式的重构


空中巴士(Airbus)、波音(Boeing)和麦道(McDonnell-Douglas)都是飞机制造商,他们都生产载客飞机(Passenger Plane)和载货飞机(Cargo Plane)。现在设计一个系统,描述这些飞机制造商以及它们所制造的飞机种类。两者类结构图如下。

不使用桥梁模式的结构图:设计模式学习笔记--桥梁(Bridge)模式_第2张图片


使用桥梁模式后的结构图:设计模式学习笔记--桥梁(Bridge)模式_第3张图片


使用场景


在以下的场景下应当使用桥梁模式:

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

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

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

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


结构模式(Structural Pattern)小结


结构模式(Structural Pattern)一共有七种,分别是:适配器模式、装饰模式、合成模式、代理模式、享元模式、门面模式、桥梁模式。

大致总结如下:

  最大特点 典型应用
适配器模式 利用对象的功能,并转换其接口 日常工作,入目尽是适配器,DAO适配,Cache功能适配,等等
装饰模式 对象层面的功能增强,接口不变 Java I/O类库的设计
合成模式 树枝、叶子同样对待 分类树、权限树等
代理模式 代表人 WebService 的本地代理,权限访问代理,引用计数代理等
享元模式 共享对象,减小内存占用 编译器系统,Java String
门面模式 统一对外接口,方便调用 基于SOA框架编程中,不同系统之间的接口
桥梁模式 解耦 大多数的驱动器,包括JDBC Driver

你可能感兴趣的:(设计模式)