桥梁模式的英文是:Decouple an abstraction from its implementation so that the two can vary independently。意思是:将抽象和实现解耦,使两者可以独立地变化。
桥梁模式有四种角色:
抽象化角色(Abstraction):该角色定义出角色的行为,并保存一个实现化角色的引用。
实现化角色(Implementor):它是接口或者是抽象类,不给出具体实现,定义出角色必须的行为或属性。
修正抽象化角色(RefinedAbstraction):它拓展抽象化角色,并引用实现化角色并对抽象化角色进行修正。
具体实现化角色(ConcreteImlementor):该角色实现实现化角色。
桥梁模式类图:
各个类对应的实现代码:
实现化角色:
package com.zz.bridge; /** * 实现化角色 * Copyright 2015年4月30日 * created by txxs * all right reserved */ public interface Implementor { //方法的实现化声明 public void operationImpl(); }具体实现化角色:
package com.zz.bridge; /** * 具体实现化角色 * Copyright 2015年4月30日 * created by txxs * all right reserved */ public class ConcreteImplementor implements Implementor { //方法的实现化实现 @Override public void operationImpl() { //业务处理代码 } }抽象化角色:
package com.zz.bridge; /** * 抽象化角色 * Copyright 2015年4月30日 * created by txxs * all right reserved */ public abstract class Abstraction { //定义对实现化角色的引用 private Implementor implementor; public Abstraction(Implementor implementor){ this.implementor = implementor; } //业务方法 public void operation(){ this.implementor.operationImpl(); } }修正化角色:
package com.zz.bridge; /** * 修正抽象化角色 * Copyright 2015年4月30日 * created by txxs * all right reserved */ public class RefineAbstraction extends Abstraction { public RefineAbstraction(Implementor implementor) { super(implementor); // TODO Auto-generated constructor stub } //修正父类的方法 public void operation(){ //业务代码 } }
1、抽象和实现分离,是为了解决继承的缺点而提出的设计模式。
2、实现对客户透明,客户端不用关心实现细节,由抽象层通过聚合完成了封装。
桥梁模式适合的场景:
1、系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免两个层次间建立静态的联系。
2、设计要求实现化角色的任何改变不应当一项客户端。
3、不希望或不适合使用继承的场合,继承具有强侵入性,即父类有的方法,子类必须有,而桥梁模式是弱关联关系。
源码下载