虚荣666
新浪微博
微信
当前位置:虚荣666网 » 警句

设计模式|装饰者模式

设计模式|装饰者模式

你站在桥上看风景,

看风景人在楼上看你。

明月装饰了你的窗子,

你装饰了别人的梦。

——《断章》


一首『断章』不知惊艳了多少人,一轮明月的点缀,一幅绝世的画面便出现在眼前……

回归正题,诗中的修饰相当巧妙,现实中的人们也被一个个人设装饰着,当人设与人不符的时候人设也就崩塌了,毕竟像「特朗普」这么本色出席的人不多了,同样的也不谁每天都能文体两开花……

当然设计模式中的「装饰者」就没有那么浪漫和复杂了,他的目的就是为了描述同一物体不同状态下的特征,比如说:你会设计,别人需要付出多少酬劳你才会帮他们设计一些他们需要的,甲方想少花钱多成果,你想多收钱少出力,不同的的要求又有不同的报价;你想喝奶茶,又想加红豆又要加蜂蜜还得是大杯的,精明的商家才不会给你免费加这些,在原来的基础上价格需要怎么变化才能不亏本……在这些应用场景中,「装饰者」便起着巨大的作用。

那么就那你晚上想喝奶茶举个栗子。

某天晚上,你看见网上有人在刷抹茶妹妹,虽然你不知道为什么是抹茶妹妹,原来的奶茶妹妹呢去哪了,但翻来覆去的你终于知道此时此刻缺少了什么,你拿起手机点了一份大杯抹茶奶茶,常温多加糖,此刻23:01,你不知道的是,同时有2333人与你同时下单,大约有666种不一样规格的奶茶,那么问题来了,在我们下单时是系统自动帮我们结账的,那么我们该如何在系统中处理不同规格奶茶的金额结算?

思路一:枚举

我称枚举为傻瓜记录,我们要在数据库中存储每一种规格的金额,列举每一种情况,显然这种方法是低效且易遗漏特殊情况的,系统负担重且用户体验差。

思路二:查表求和

从数据库中将所选规格的子规格的金额读出,进行求和,如:将大杯小杯等金额进行求和。这是比较常见的思路,这种思路需要对数据库合理的设计,否则会影响系统的性能。

思路三:使用装饰者模式

类图:

同样拿奶茶来讲解类图,BaseClass可以代指普通奶茶,在这里可以添加大杯中杯小杯等属性,然后我们可以用DecoratorClass1来代指抹茶,DecoratorClass2来代指加糖量,用这些来「装饰」奶茶, 当我们来计算价格的时候,我们在method()方法中计算本装饰者的价格以及调用父类的method()方法,以递归的形式来运算,返回相应的价格。

在这里抹茶、糖量就是我们所说的「装饰者」,上述的流程便是『装饰者模式』,在面向对象的编程语言中,我们通过对父类的集成,对相同方法的重写,来实现装饰者模式,在Python中,函数的装饰器便是此模式的典型案例,通过装饰器来加强函数的功能。


Python 实现



设计模式并不是在任意的应用场景下都适用,需要区分对待,这里举的例子也不是最合适的,毕竟设计模式也是人们在长期的开发过程中总结出来的一套经验方法,在开发中主动的总结不用应用场景下的方法,对设计模式的理解会事半功倍,合理的设计同样也会让开发效率、程序运行效率有显著的提高。