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

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

对于“设计模式”这个词大家肯定都不陌生,很多框架也用到了设计模式,但是大部分的开发者应该是没有深入的了解过,我准备硬肝下这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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

沉淀顶峰相见的PET

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

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

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

打赏作者

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

抵扣说明:

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

余额充值