1、桥接模式
在现实生活中,某些类具有两个或多个维度的变化,如图形既可按形状分,又可按颜色分。如何设计类似于 Photoshop 这样的软件,能画不同形状和不同颜色的图形呢?如果用继承方式,m 种形状和 n 种颜色的图形就有 m×n 种,不但对应的子类很多,而且扩展困难。
当然,这样的例子还有很多,如不同颜色和字体的文字、不同品牌和功率的汽车、不同性别和职业的男女、支持不同平台和不同文件格式的媒体播放器等。如果用桥接模式就能很好地解决这些问题。
1.2、桥接模式的定义与特点
桥接(Bridge)模式的定义如下:将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现,从而降低了抽象和实现这两个可变维度的耦合度。
通过上面的讲解,我们能很好的感觉到桥接模式遵循了里氏替换原则和依赖倒置原则,最终实现了开闭原则,对修改关闭,对扩展开放。这里将桥接模式的优缺点总结如下。
桥接(Bridge)模式的优点是:
- 抽象与实现分离,扩展能力强
- 符合开闭原则
- 符合合成复用原则
- 其实现细节对客户透明
缺点是:由于聚合关系建立在抽象层,要求开发者针对抽象化进行设计与编程,能正确地识别出系统中两个独立变化的维度,这增加了系统的理解与设计难度。
1.3、桥接模式的结构与实现
可以将抽象化部分与实现化部分分开,取消二者的继承关系,改用组合关系。
桥接(Bridge)模式包含以下主要角色。
- 抽象化(Abstraction)角色:定义抽象类,并包含一个对实现化对象的引用。
- 扩展抽象化(Refined Abstraction)角色:是抽象化角色的子类,实现父类中的业务方法,并通过组合关系调用实现化角色中的业务方法。
- 实现化(Implementor)角色:定义实现化角色的接口,供扩展抽象化角色调用。
- 具体实现化(Concrete Implementor)角色:给出实现化角色接口的具体实现。
2、应用实例
用桥接(Bridge)模式模拟女士皮包的选购。
分析:女士皮包有很多种,可以按用途分、按皮质分、按品牌分、按颜色分、按大小分等,存在多个维度的变化,所以采用桥接模式来实现女士皮包的选购比较合适。
本实例按用途分可选钱包(Wallet)和挎包(HandBag),按颜色分可选黄色(Yellow)和红色(Red)。可以按两个维度定义为颜色类和包类。(点此下载本实例所要显示的包的图片)。
颜色类(Color)是一个维度,定义为实现化角色,它有两个具体实现化角色:黄色和红色,通过 getColor() 方法可以选择颜色;包类(Bag)是另一个维度,定义为抽象化角色,它有两个扩展抽象化角色:挎包和钱包,它包含了颜色类对象,通过 getName() 方法可以选择相关颜色的挎包和钱包。
客户类通过 ReadXML 类从 XML 配置文件中获取包信息(点此下载 XML 配置文件),并把选到的产品通过窗体显示出现。
/**
* @ClassName: BagManage
* @Description:
* @Author: DiTian
* @Date: 2021/7/23 4:03
*/
public class BagManage {
public static void main(String[] args) {
Color color;
Bag bag;
color = (Color)ReadXML.getObject("color");
bag = (Bag) ReadXML.getObject("bag");
bag.SetColor(color);
String name = bag.getName();
show(name);
}
private static void show(String name) {
JFrame jFrame = new JFrame("桥接模式测试");
Container contentPane = jFrame.getContentPane();
JPanel jPanel = new JPanel();
JLabel jLabel = new JLabel(new ImageIcon("src/com/ditian/design/bridge/" + name + ".jpg"));
jPanel.setLayout(new GridLayout(1,1));
jPanel.setBorder(BorderFactory.createTitledBorder("女式皮包"));
jPanel.add(jLabel);
contentPane.add(jPanel,BorderLayout.CENTER);
jFrame.pack();
jFrame.setVisible(true);
jFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}
//实现化角色:颜色
interface Color{
String getColor();
}
//具体实现化角色:黄色
class Yellow implements Color{
@Override
public String getColor() {
return "yellow";
}
}
//具体实现化角色:红色
class Red implements Color{
@Override
public String getColor() {
return "red";
}
}
//抽象化角色:包
abstract class Bag{
protected Color color;
public void SetColor(Color color){
this.color = color;
}
public abstract String getName();
}
//扩展抽象化角色:挎包
class HandBag extends Bag{
@Override
public String getName() {
return color.getColor()+"HandBag";
}
}
//扩展抽象化角色:钱包
class Wallet extends Bag{
@Override
public String getName() {
return color.getColor()+"Wallet";
}
}
class ReadXML{
public static Object getObject(String args){
try {
DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = builderFactory.newDocumentBuilder();
Document doc;
doc = builder.parse(new File("src/com/ditian/design/bridge/config2.xml"));
NodeList nl = doc.getElementsByTagName("className");
Node classNode = null;
if (args.equals("color")){
classNode = nl.item(0).getFirstChild();
}else if (args.equals("bag")){
classNode = nl.item(1).getFirstChild();
}
String cName = "com.ditian.design.bridge."+classNode.getNodeValue();
System.out.println("新类名:"+cName);
Class<?> c = Class.forName(cName);
Object o = c.newInstance();
return o;
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
config2.xml 文件:
<?xml version="1.0" encoding="UTF-8"?>
<config>
<className>Red</className>
<className>Wallet</className>
</config>
测试结果:
3、桥接模式的应用场景
当一个类内部具备两种或多种变化维度时,使用桥接模式可以解耦这些变化的维度,使高层代码架构稳定。
桥接模式通常适用于以下场景。
- 当一个类存在两个独立变化的维度,且这两个维度都需要进行扩展时。
- 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
- 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。
桥接模式的一个常见使用场景就是替换继承。我们知道,继承拥有很多优点,比如,抽象、封装、多态等,父类封装共性,子类实现特性。继承可以很好的实现代码复用(封装)的功能,但这也是继承的一大缺点。
因为父类拥有的方法,子类也会继承得到,无论子类需不需要,这说明继承具备强侵入性(父类代码侵入子类),同时会导致子类臃肿。因此,在设计模式中,有一个原则为优先使用组合/聚合,而不是继承。
因为父类拥有的方法,子类也会继承得到,无论子类需不需要,这说明继承具备强侵入性(父类代码侵入子类),同时会导致子类臃肿。因此,在设计模式中,有一个原则为优先使用组合/聚合,而不是继承。
[外链图片转存中…(img-4LbFhY59-1626986338494)]
很多时候,我们分不清该使用继承还是组合/聚合或其他方式等,其实可以从现实语义进行思考。因为软件最终还是提供给现实生活中的人使用的,是服务于人类社会的,软件是具备现实场景的。当我们从纯代码角度无法看清问题时,现实角度可能会提供更加开阔的思路。