硬肝系列:23种设计模式之装饰器模式

装饰器模式实战:扩展功能而不修改源代码
本文通过实例讲解装饰器模式,如何在不破坏现有代码结构下动态添加功能,避免类的大量继承。通过Shape和ChromaticShape例子,展示装饰器模式在管理复杂组件扩展上的优势。

用示例代码来帮你了解装饰器模式

对于“设计模式”这个词大家肯定都不陌生,很多框架也用到了设计模式,但是大部分的开发者应该是没有深入的了解过,我准备硬肝下这23设计模式作为专题文章的开端,一共23种设计模式,我尽量在<23天肝完。

为什么要学习设计模式:https://blog.youkuaiyun.com/kaituozhe_sh/article/details/107922339

在我大学四年,对设计模式也没有什么概念,写代码就想着能实现就可以了,不会有设计模式那样的思想,但是当学习到了框架的时候,对于设计模式才有了一些更深入的了解,使用设计模式的代码在扩展性上会比暴力的代码更容易维护,特别是当一个程序猿离职了后,你去接手它的代码,里面是一大堆if else,这样真的会崩溃,修改都不知道从何下手
在这里插入图片描述

硬肝系列目录

创建型模式

23种设计模式之工厂模式

23种设计模式之抽象工厂模式

23种设计模式之建造者模式

23种设计模式之原型模式

23种设计模式之单例模式

结构型模式

23种设计模式之适配器模式

23种设计模式之桥梁模式

23种设计模式之代理模式

23种设计模式之外观模式

23种设计模式之装饰器模式

23种设计模式之享元模式

23种设计模式之组合模式

行为型模式

23种设计模式之责任链模式

23种设计模式之命令模式

23种设计模式之迭代器模式

23种设计模式之中介者模式

23种设计模式之备忘录模式

23种设计模式之观察者模式

到目前为止、23种设计模式的创建型模式已经给大家肝完了,现在我们进入到一个全新的章节,结构型模式!!!

什么是装饰器模式?为什么要有装饰器模式?

装饰器模式的定义我是这样理解的,它是动态地将责任附加到对象上,而如果用原来的方法,当我们一个类需要扩展功能的时候,最好的方法是写一个类继承它的方法,再向继承类中添加随需要的新功能,但是会出现两个问题
1.如果是final类你怎么继承扩展功能呢?
2.下表格

时间需求
2021/3/01市场部姐姐:小哥哥,客户那边想给我们的一个功能稍微扩展新功能诶,你看看多久能给人家弄出来嘛 ------你内心ps:小姐姐都这么说了,我肯定要展现我男人的雄风啊 你说:我现在就给你弄出来!! 市场部姐姐:哇你好厉害,我好喜欢
2021/3/02市场部姐姐:小哥哥,客户那边又又想给我们的一个功能稍微扩展新功能诶,你看看多久能给人家弄出来嘛 ------经过昨天的奋战,你内心ps:MMP,什么公司啊,又加功能,但是小姐姐又都这么说了,我肯定要展现我男人的雄风啊 你说:我现在就给你弄出来呜呜呜
2021/3/03市场部姐姐:小哥哥,客户那边又双叒叕想给我们的一个功能稍微扩展新功能诶,你看看多久能给人家弄出来嘛 ------经过昨天的奋战,你内心ps:MMP,什么公司啊,我不干了啊啊啊啊啊又加功能,但是为了小姐姐的芳心 你说:我今天就给你弄出来
日复一日,年复一年,领导来检查项目了,发现这个类下面有一百个子类看了一看功能,和另一个类下面的子类有着重复的子类,还是巨多重复的子类,大发雷霆,于是小程序猿和市场部小姐姐手牵着手离开了公司,过上了没羞没臊的幸福生活

从上面的例子我们可以发现什么问题,只要功夫深就可以把小姐姐带回家嘻嘻嘻嘻
猥琐1
不对不对,我们还是先把装饰器模式给大家讲完咳咳咳

对于上面的情况,在不破坏之前的代码下扩展新功能,继承类重写方法的确是最好的解决方法,但是为什么我们不把这些继承的子类交给一个总类来管理呢,这就引出了我们的装饰器模式了,先给大家上一幅图
在这里插入图片描述
从上图可以看到,实现装饰器模式,就是用一个装饰器抽象类实现顶层接口,装饰器的属性可包含其实现接口,然后使用一个装饰器继承类实现其装饰器抽象类,在装饰器继承类中实现新增功能的写入

上代码给大家感受一下

定义一个顶级接口Shape,里面包含一个create()

public interface Shape {
    void create();
}

写两个基本实现类来实现Shape

public class Circular implements Shape{
    @Override
    public void create() {
        System.out.println("i'm circular---");
    }
}

public class Trapezoid implements Shape{
    @Override
    public void create() {
        System.out.println("i'm trapezoid");
    }
}

然后定义一个装饰器抽象类来实现Shape接口,里面的属性包含Shape

public abstract class ShapeDecorator implements Shape{
    Shape shapeDecorators;

    public ShapeDecorator(Shape shapeDecorators) {
        this.shapeDecorators = shapeDecorators;
    }

    public void create(){
        shapeDecorators.create();
    }
}

定义一个类来继承该装饰器类

public class ChromaticShape extends ShapeDecorator{
    public ChromaticShape(Shape shapeDecorators) {
        super(shapeDecorators);
    }
    public void create(){
        newMethod1();
        shapeDecorators.create();
    }

    public void newMethod1(){
        System.out.println("有些可贵的东西,很可能就是你看不惯的、带个性色彩的东西");
    }
}

可以看到,我们的继承类中新写了一个方法,并在接口实现类的方法中调用了它,到这就完成了我们装饰器模式的编写啦

如果用以前的方法,如果我有100个形状和一百个颜色呢?难道每一个形状都要写100个子类继承它吗?这显然是不现实的,所以我们使用了装饰器类来解决这个问题

这里会有人问了,那我使用代理模式来解决不行吗?

首先我们先来看看装饰器模式和代理模式的区别

代理模式和装饰器模式都持有RealObject(被代理的对象/被装饰的对象)

代理模式更注重的是控制对象的访问,并不关心对象本身它要做什么,我只负责控制你周围的东西,做被代理对象做不到的事而且代理是创造出一个新的代理对象,使用代理对象来控制被代理对象周围事务的行为

而装饰器模式更注重的是为被装饰的对象添加装饰,但是我还是可以执行我自己的功能

而装饰器模式与桥梁模式的区别又在哪呢?

看过我桥梁模式的文章都知道我说过这么一句话,桥梁模式是对要建立桥梁的对象,从它的属性入手,将不属于它本质的东西抽象出来,抽象出来的可以是大部分对象共同拥有的特质

装饰模式:形状(三角形、梯形…) 创建了形状我可以往里填充颜色吧,可以在里面画画吧,而这些行为就是对形状的装饰

桥接模式:形状(三角形…) 、色彩(红橙黄绿…) 将形状与色彩抽象出来自由组合

还有就是你夏天短袖、秋天外套、冬天羽绒服,你本身还是你吧,你并没有改变,而是根据天气(也就是客户需求)而装饰的你自己,最终呈现出来的一个装饰品

完成:TO: 2021/3/23 15:33

采用PyQt5框架与Python编程语言构建图书信息管理平台 本项目基于Python编程环境,结合PyQt5图形界面开发库,设计实现了一套完整的图书信息管理解决方案。该系统主要面向图书馆、书店等机构的日常运营需求,通过模块化设计实现了图书信息的标准化管理流程。 系统架构采用典型的三层设计模式,包含数据存储层、业务逻辑层用户界面层。数据持久化方案支持SQLite轻量级数据库与MySQL企业级数据库的双重配置选项,通过统一的数据库操作接口实现数据存取隔离。在数据建模方面,设计了包含图书基本信息、读者档案、借阅记录等核心数据实体,各实体间通过主外键约束建立关联关系。 核心功能模块包含六大子系统: 1. 图书编目管理:支持国际标准书号、中国图书馆分类法等专业元数据的规范化著录,提供批量导入与单条录入两种数据采集方式 2. 库存动态监控:实时追踪在架数量、借出状态、预约队列等流通指标,设置库存预警阈值自动提醒补货 3. 读者服务管理:建立完整的读者信用评价体系,记录借阅历史与违规行为,实施差异化借阅权限管理 4. 流通业务处理:涵盖借书登记、归还处理、续借申请、逾期计算等标准业务流程,支持射频识别技术设备集成 5. 统计报表生成:按日/月/年周期自动生成流通统计、热门图书排行、读者活跃度等多维度分析图表 6. 系统维护配置:提供用户权限分级管理、数据备份恢复、操作日志审计等管理功能 在技术实现层面,界面设计遵循Material Design设计规范,采用QSS样式表实现视觉定制化。通过信号槽机制实现前后端数据双向绑定,运用多线程处理技术保障界面响应流畅度。数据验证机制包含前端格式校验与后端业务规则双重保障,关键操作均设有二次确认流程。 该系统适用于中小型图书管理场景,通过可扩展的插件架构支持功能模块的灵活组合。开发过程中特别注重代码的可维护性,采用面向对象编程范式实现高内聚低耦合的组件设计,为后续功能迭代奠定技术基础。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

python牛牛

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值