当前位置: 首页 > article >正文

设计模式之桥梁模式

什么是桥梁模式

桥梁模式(Bridge Pattern)也称为桥接模式,属于结构型模式,它主要目的是通过组合的方式建立两个类之间的联系,而不是继承。桥梁模式将抽象部分与它的具体实现部分分离,使它们都可以独立地变化。

桥梁模式的核心角色

桥梁模式的实现通常包括以下四个角色:

  1. Abstraction——抽象化角色:它的主要职责是定义出该角色的行为,同时保存一个对实现化角色的引用,该角色一般是抽象类。
  2. Implementor——实现化角色:它是接口或者抽象类,定义角色必需的行为和属性。
  3. RefinedAbstraction——修正抽象化角色:它引用实现化角色对抽象化角色进行修正。
  4. ConcreteImplementor——具体实现化角色:它实现接口或抽象类定义的方法和属性。

桥梁模式如何实现

小王是一个富二代,家里的产业很多,开煤矿、搞房地产等等,如果设计一个程序来帮助小王来管理家族产业,那么应该怎么实现呢?这里就可以使用桥梁模式来实现。为什么可以使用桥梁模式呢?原因是这样的,小王家大业大、善于投资,这些产业可能会发生变化,比如煤矿不挣钱了,就改搞新能源;如果房地产不挣钱了,那就搞酒店住宿,可以看出来具体的业务可能会发生变化;那有没有不会发生变化的东西?当然有。这么大的产业,一般会成立一些子公司分别来管理这些产业,然后通过一个母公司来控制这些子公司。

那这里的母公司就是抽象化角色(Abstraction),子公司就是实现化角色(RefinedAbstraction),这些不同的产业可以抽象为产品类,即实现化角色(Implementor),产品有两个共同的行为,被生出来、被销售出去,煤碳、房产等这些就是具体的具体实现化角色(ConcreteImplementor),下面就用代码来演示一个这个过程:

  1. MotherCompany:抽象化母公司,属于抽象化角色(Abstraction)
  2. CoalCompany:煤炭公司袱类,属于实现化角色(RefinedAbstraction)
  3. HouseCompany:房产公司类,继承于MotherCompany,属于具体实现化角色(ConcreteImplementor)
  4. Product:抽象产品类,即实现化角色(Implementor)
  5. House:房产实体类,继承于Product,属于具体实现化角色(ConcreteImplementor)
  6. Coal,煤炭实体类,继承于Product,属于具体实现化角色(ConcreteImplementor)
/**
 * 抽象产品,实现化角色(Implementor)
 */
public abstract class Product {
    /**
     * 被生产出来
     */
    public abstract void  beProduted();

    /**
     * 被销售出去
     */
    public abstract void beSelled();
}
/**
 * 煤炭,具体实现化角色(ConcreteImplementor)
 */
public class Coal  extends Product{
    @Override
    public void beProduted() {
        System.out.println("煤炭生产");
    }

    @Override
    public void beSelled() {
        System.out.println("煤炭销售");
    }
}
/**
 * 房产,具体实现化角色(ConcreteImplementor)
 */
public class House extends Product{
    @Override
    public void beProduted() {
        System.out.println("房产生产");
    }

    @Override
    public void beSelled() {
        System.out.println("房产销售");
    }
}
/**
 * 母公司就是抽象化角色(Abstraction)
 */
public abstract class MotherCompany {
    private Product product;

    public MotherCompany(Product product) {
        this.product = product;
    }

    public void mange(){
        this.product.beProduted();
        this.product.beSelled();
    }
}
/**
 * 煤炭公司,实现化角色(RefinedAbstraction)
 */
public class CoalCompany extends MotherCompany{
    public CoalCompany(Product product) {
        super(product);
    }

    @Override
    public void mange() {
        super.mange();
        System.out.println("今年煤炭生意火爆");
    }
}
/**
 * 房产公司,实现化角色(RefinedAbstraction)
 */
public class HouseCompany extends MotherCompany{
    public HouseCompany(Product product) {
        super(product);
    }

    @Override
    public void mange() {
        super.mange();
        System.out.println("今年房地产生意不好");
    }
}
public class Test {
    public static void main(String[] args) {
        Product product=new Coal();
        MotherCompany motherCompany=new CoalCompany(product);
        motherCompany.mange();
        System.out.println("----------------");
        product=new House();
        motherCompany=new HouseCompany(product);
        motherCompany.mange();
    }
}

如果小王家又新增投资旅游产业,开了一家景点经营公司,怎么办呢?新增一个旅游公司的类、门票类,就可以了,原来的业务不用改,完全符合开闭原则

/**
 * 门票
 */
public class Ticket extends Product {
    @Override
    public void beProduted() {
        System.out.println("印刷门票");
    }

    @Override
    public void beSelled() {
        System.out.println("卖门票");
    }
}
/**
 * 旅游公司
 */
public class TourismCompany extends MotherCompany{
    public TourismCompany(Product product) {
        super(product);
    }

    @Override
    public void mange() {
        super.mange();
        System.out.println("旅游人数爆火");
    }
}
public class Test {
    public static void main(String[] args) {
        Product  product=new Ticket();
        MotherCompany motherCompany=new TourismCompany(product);
        motherCompany.mange();
    }
}

桥梁模式的适用场景

桥梁模式的应用场景包括:

  1. 当你想要解耦抽象和具体类时,例如在软件系统中,抽象和具体的功能经常需要变化,而通过使用桥梁模式,你可以将它们解耦,使得你可以在不改变其他部分的情况下更改它们。
  2. 当你需要实现可扩展的软件系统时,桥梁模式可以帮助你实现更灵活的架构,因为你可以在不影响其他部分的情况下添加新的具体实现。
  3. 当你需要隐藏实现的细节时,桥梁模式可以帮助你隐藏实现的细节,只暴露公共接口,这样客户端只需要和抽象类打交道,不需要关心具体的实现细节。

总结

优点

创建灵活且易于扩展的软件产品、简化客户端代码、易于维护和修改等。

缺点

如增加系统的复杂性和理解难度、需要正确地识别出系统中两个独立变化的维度、需要对系统进行递归处理等。

总的来说,桥梁模式是一种结构型设计模式,它通过将抽象和具体解耦,使得它们可以独立地变化,从而提高了系统的灵活性和可扩展性,但同时也需要仔细考虑和设计才能正确应用。

 


http://www.kler.cn/a/107736.html

相关文章:

  • AcWing 302 任务安排 斜率优化的dp
  • 基于Python+Django+Vue3+MySQL实现的前后端分类的商场车辆管理系统
  • IPguard与Ping32全面对比——选择最适合企业的数据安全解决方案
  • 10款翻译工具实践体验感受与解析!!!!!
  • Hadoop(环境搭建篇)
  • RAG综述:《A Comprehensive Survey of Retrieval-Augmented Generation (RAG)》
  • 系统日志记录注解方式动态记录
  • 【psychopy】【脑与认知科学】认知过程中的面孔识别加工
  • [SpringCloud] Nacos 简介
  • 重要环节不可忽视,CSS性能优化引领用户体验!
  • ubuntu执行普通用户或root用户执行apt-get update时报错Couldn‘t create temporary file /tmp/...
  • 苹果cms模板MXone V10.6魔改版网站源码短视大气海报样式
  • FOC系列(二)----继续学习DRV8301芯片
  • 机器学习之查准率、查全率与F1
  • 虎去兔来(C++)
  • Bootstrap的咖啡网站实例代码阅读笔记
  • 蓝桥杯每日一题2023.10.25
  • VR结合|山海鲸虚拟展厅解决方案
  • bitlocker 加密锁定的固态硬盘,更换到别的电脑上,怎么把原密钥写进新电脑TPM芯片内,开启无需手动填密钥
  • Spring Boot进阶(93):体验式教程:手把手教你整合Spring Boot和Zipkin
  • 独立开发者知识贴
  • 初始化固定长度的数组
  • MySQL---表的增查改删(CRUD基础)
  • 【多线程面试题 六】、 如何实现线程同步?
  • 文件包含漏洞(3),日志利用, 图片木马利用
  • 利用Pholcus框架提取小红书数据的案例分析