设计模式系列 — 桥接模式
点赞再看,养成习惯,公众号搜一搜【一角钱技术】关注更多原创技术文章。本文 GitHub org_hejianhui/JavaStudy 已收录,有我的系列文章。
前言
- 23种设计模式速记
- 单例(singleton)模式
- 工厂方法(factory method)模式
- 抽象工厂(abstract factory)模式
- 建造者/构建器(builder)模式
- 原型(prototype)模式
- 享元(flyweight)模式
- 外观(facade)模式
- 适配器(adapter)模式
- 装饰(decorator)模式
- 观察者(observer)模式
- 策略(strategy)模式
- 持续更新中......
23种设计模式快速记忆的请看上面第一篇,本篇和大家一起来学习桥接模式相关内容。
模式定义
将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个可变维度的耦合度。
模式实现如下:
package com.niuh.designpattern.bridge.v1;
/**
* 桥接模式
*/
public class BridgePattern {
public static void main(String[] args) {
Implementor imple=new ConcreteImplementorA();
Abstraction abs=new RefinedAbstraction(imple);
abs.Operation();
}
}
//实现化角色
interface Implementor {
void OperationImpl();
}
//具体实现化角色
class ConcreteImplementorA implements Implementor {
public void OperationImpl() {
System.out.println("具体实现化(Concrete Implementor)角色被访问");
}
}
//抽象化角色
abstract class Abstraction {
protected Implementor imple;
protected Abstraction(Implementor imple) {
this.imple = imple;
}
public abstract void Operation();
}
//扩展抽象化角色
class RefinedAbstraction extends Abstraction {
protected RefinedAbstraction(Implementor imple) {
super(imple);
}
public void Operation() {
System.out.println("扩展抽象化(Refined Abstraction)角色被访问");
imple.OperationImpl();
}
}
输出结果如下:
扩展抽象化(Refined Abstraction)角色被访问
具体实现化(Concrete Implementor)角色被访问
解决的问题
在有多种可能会变化的情况下,用继承会造成类爆炸问题,扩展起来不灵活。
模式组成
可以将抽象化部分与实现化部分分开,取消二者的继承关系,改用组合关系。
组成(角色) | 作用 |
---|---|
抽象化(Abstraction)角色 | 定义抽象类,并包含一个对实现化对象的引用 |
扩展抽象化(Refined Abstraction)角色 | 是抽象化角色的子类,实现父类中的业务方法,并通过组合关系调用实现化角色中的业务方法 |
实现化(Implementor)角色 | 定义实现化角色的接口,供扩展抽象化角色调用 |
具体实现化(Concrete Implementor)角色 | 给出实现化角色接口的具体实现 |
实例说明
实例概况
某公司开发了一个财务管理系统,其中有个报表生成器的工具模块,客户可以指定任意一种报表类型,如基本报表,往来报表,资金报表,资产报表等,并且可以指定不同 的报表样式,如饼图,柱状图等。系统设计人员针对这个报表生成器的结构设计了如下图所示的类图。
后来在客户使用过程中,客户又希望增加一个新的报表和新的线形图,开发人员这个时候发现维护起来非常麻烦,设计人员经过仔细分析,发现存在严重的问题,因为新增加一个报表或者图,需要增加很多子类。所以,系统分析师最终对这个模块根据面向对象的设计原则对上面的方案进行了重构,重构后的图如下所示。
在本重构方案中,将报表和图形设计成两个继承结构,两者都可以独立变化,编程的时候可以只针对抽象类编码,而在运行的时候再将具体的图形子类对象注入到具体的 报表类中。这样的话,系统就具有良好的可扩展性和可维护性,并且满足了面向对象设计原则的开闭原则。
使用步骤
步骤1:定义实现化角色,报表接口
interface IReport {
void operationImpl();
}
步骤2:定义具体实现化角色(基本报表、往来报表、资金报表)
class BasicReport implements IReport {
@Override
public void operationImpl() {
System.out.println("基本报表被访问.");
}
}
class IntercourseReport implements IReport {
@Override
public void operationImpl() {
System.out.println("往来报表被访问.");
}
}
class CapitalReport implements IReport {
@Override
public void operationImpl() {
System.out.println("资金报表被访问.");
}
}
步骤3:定义抽象化角色,图形
abstract class AbstractionGraph {
protected IReport iReport;
public AbstractionGraph(IReport iReport) {
this.iReport = iReport;
}
abstract void operation();
}
步骤4:定义扩展抽象化角色(柱状图、饼图)
class Barchart extends AbstractionGraph {
public Barchart(IReport iReport) {
super(iReport);
}
@Override
void operation() {
System.out.println("柱状图被访问.");
iReport.operationImpl();
}
}
class Piechart extends AbstractionGraph {
public Piechart(IReport iReport) {
super(iReport);
}
@Override
void operation() {
System.out.println("饼图被访问.");
iReport.operationImpl();
}
}
步骤5:测试
public class BridgePattern {
public static void main(String[] args) {
//实现化和抽象化分离
// 基本报表
IReport basicReport = new BasicReport();
// 往来报表
IReport intercourseReport = new IntercourseReport();
// 资金报表
IReport capitalReport = new CapitalReport();
// 基本报表使用柱状图
AbstractionGraph barchart = new Barchart(basicReport);
barchart.operation();
// 基本报表使用饼图
AbstractionGraph piechart = new Piechart(basicReport);
piechart.operation();
}
}
输出结果
柱状图被访问.
基本报表被访问.
饼图被访问.
基本报表被访问.
优点
桥接模式遵循了里氏替换原则和依赖倒置原则,最终实现了开闭原则,对修改关闭,对扩展开放。这里将桥接模式的优缺点总结如下。
桥接(Bridge)模式的优点:
- 抽象与实现分离,扩展能力强
- 符合开闭原则
- 符合合成复用原则
- 其实现细节对客户透明
缺点
由于聚合关系建立在抽象层,要求开发者针对抽象化进行设计与编程,能正确地识别出系统中两个独立变化的维度,这增加了系统的理解与设计难度。
应用场景
当一个类内部具备两种或多种变化维度时,使用桥接模式可以解耦这些变化的维度,使高层代码架构稳定。
桥接模式通常适用于以下场景:
- 当一个类存在两个独立变化的维度,且这两个维度都需要进行扩展时;
- 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时;
- 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。
桥接模式的一个常见使用场景就是替换继承。我们知道,继承拥有很多优点,比如,抽象、封装、多态等,父类封装共性,子类实现特性。继承可以很好的实现代码复用(封装)的功能,但这也是继承的一大缺点。
因为父类拥有的方法,子类也会继承得到,无论子类需不需要,这说明继承具备强侵入性(父类代码侵入子类),同时会导致子类臃肿。因此,在设计模式中,有一个原则为优先使用组合/聚合,而不是继承。
桥接模式模式的扩展
在软件开发中,有时桥接(Bridge)模式可与适配器模式联合使用。当桥接(Bridge)模式的实现化角色的接口与现有类的接口不一致时,可以在二者中间定义一个适配器将二者连接起来,其结构图如下:
源码中的应用
JDBC驱动程序
......
image
DriverManager类
DriverManager
作为一个抽象化角色,聚合了实现化角色Connection
,只不过与标准的桥梁模式不一样的是,DriverManager
类下面没有子类。
// Worker method called by the public getConnection() methods.
private static Connection getConnection(
String url, java.util.Properties info, Class<?> caller) throws SQLException {
/*
* When callerCl is null, we should check the application's
* (which is invoking this class indirectly)
* classloader, so that the JDBC driver class outside rt.jar
* can be loaded from here.
*/
ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
synchronized(DriverManager.class) {
// synchronize loading of the correct classloader.
if (callerCL == null) {
callerCL = Thread.currentThread().getContextClassLoader();
}
}
if(url == null) {
throw new SQLException("The url cannot be null", "08001");
}
println("DriverManager.getConnection(\"" + url + "\")");
// Walk through the loaded registeredDrivers attempting to make a connection.
// Remember the first exception that gets raised so we can reraise it.
SQLException reason = null;
for(DriverInfo aDriver : registeredDrivers) {
// If the caller does not have permission to load the driver then
// skip it.
if(isDriverAllowed(aDriver.driver, callerCL)) {
try {
println(" trying " + aDriver.driver.getClass().getName());
Connection con = aDriver.driver.connect(url, info);
if (con != null) {
// Success!
println("getConnection returning " + aDriver.driver.getClass().getName());
return (con);
}
} catch (SQLException ex) {
if (reason == null) {
reason = ex;
}
}
} else {
println(" skipping: " + aDriver.getClass().getName());
}
}
// if we got here nobody could connect.
if (reason != null) {
println("getConnection failed: " + reason);
throw reason;
}
println("getConnection: no suitable driver found for "+ url);
throw new SQLException("No suitable driver found for "+ url, "08001");
}
PS:以上代码提交在 Github :https://github.com/Niuh-Study/niuh-designpatterns.git
文章持续更新,可以公众号搜一搜「 一角钱技术 」第一时间阅读, 本文 GitHub org_hejianhui/JavaStudy 已经收录,欢迎 Star。