用示例代码来帮你了解装饰器模式
对于“设计模式”这个词大家肯定都不陌生,很多框架也用到了设计模式,但是大部分的开发者应该是没有深入的了解过,我准备硬肝下这23设计模式作为专题文章的开端,一共23种设计模式,我尽量在<23天肝完。
为什么要学习设计模式:https://blog.youkuaiyun.com/kaituozhe_sh/article/details/107922339
在我大学四年,对设计模式也没有什么概念,写代码就想着能实现就可以了,不会有设计模式那样的思想,但是当学习到了框架的时候,对于设计模式才有了一些更深入的了解,使用设计模式的代码在扩展性上会比暴力的代码更容易维护,特别是当一个程序猿离职了后,你去接手它的代码,里面是一大堆if else,这样真的会崩溃,修改都不知道从何下手
硬肝系列目录
创建型模式
结构型模式
行为型模式
到目前为止、23种设计模式的创建型模式已经给大家肝完了,现在我们进入到一个全新的章节,结构型模式!!!
什么是装饰器模式?为什么要有装饰器模式?
装饰器模式的定义我是这样理解的,它是动态地将责任附加到对象上,而如果用原来的方法,当我们一个类需要扩展功能的时候,最好的方法是写一个类继承它的方法,再向继承类中添加随需要的新功能,但是会出现两个问题
1.如果是final类你怎么继承扩展功能呢?
2.下表格
时间 | 需求 |
---|---|
2021/3/01 | 市场部姐姐:小哥哥,客户那边想给我们的一个功能稍微扩展新功能诶,你看看多久能给人家弄出来嘛 ------你内心ps:小姐姐都这么说了,我肯定要展现我男人的雄风啊 你说:我现在就给你弄出来!! 市场部姐姐:哇你好厉害,我好喜欢 |
2021/3/02 | 市场部姐姐:小哥哥,客户那边又又想给我们的一个功能稍微扩展新功能诶,你看看多久能给人家弄出来嘛 ------经过昨天的奋战,你内心ps:MMP,什么公司啊,又加功能,但是小姐姐又都这么说了,我肯定要展现我男人的雄风啊 你说:我现在就给你弄出来呜呜呜 |
2021/3/03 | 市场部姐姐:小哥哥,客户那边又双叒叕想给我们的一个功能稍微扩展新功能诶,你看看多久能给人家弄出来嘛 ------经过昨天的奋战,你内心ps:MMP,什么公司啊,我不干了啊啊啊啊啊又加功能,但是为了小姐姐的芳心 你说:我今天就给你弄出来 |
… | 日复一日,年复一年,领导来检查项目了,发现这个类下面有一百个子类看了一看功能,和另一个类下面的子类有着重复的子类,还是巨多重复的子类,大发雷霆,于是小程序猿和市场部小姐姐手牵着手离开了公司,过上了没羞没臊的幸福生活 |
从上面的例子我们可以发现什么问题,只要功夫深就可以把小姐姐带回家嘻嘻嘻嘻
不对不对,我们还是先把装饰器模式给大家讲完咳咳咳
对于上面的情况,在不破坏之前的代码下扩展新功能,继承类重写方法的确是最好的解决方法,但是为什么我们不把这些继承的子类交给一个总类来管理呢,这就引出了我们的装饰器模式了,先给大家上一幅图
从上图可以看到,实现装饰器模式,就是用一个装饰器抽象类实现顶层接口,装饰器的属性可包含其实现接口,然后使用一个装饰器继承类实现其装饰器抽象类,在装饰器继承类中实现新增功能的写入
上代码给大家感受一下
定义一个顶级接口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