【读书活动感悟分享】极客充电队——《Head First 设计模式》第三章装饰者模式读书心得

装饰者模式的引入

书中以星巴兹咖啡订单系统为例，若用继承方式实现带不同调料的咖啡类，会导致 “类爆炸”，且难以应对调料价格变化、新增调料等情况，不符合 “对扩展开放，对修改关闭” 的设计原则。因此需要一种更灵活的方式来扩展对象功能。

装饰者模式的定义

装饰者模式动态地将额外责任附加到对象上。对于扩展功能，装饰者提供子类化之外的弹性替代方案。

装饰者模式的结构与实现

在咖啡订单系统中，Beverage是饮料的父类，具体的饮料类与调味料类都是它的子类。调味料类作为装饰器，在调用cost函数时，先调用饮料类的cost，然后加上该调味料的价格，算出总价格。





在项目中的实际应用：电站基因计算

该需求的背景是：基于电站当前所包含的要素，得出该电站是【基因好】还是【基因差】的结论。 而要素包括：运营时间是否为24小时、是否贼APP显示等。

通过将每个因素抽象为不同的装饰器，经过层级的依次嵌套，形成一个调用链，由客户端完成调用，得到最终的结果。

个人观点



装饰者模式是一个类似“套娃”的结构，通过在不改变原有类的基础上，给原来的类添加功能的设计模式。

单看这个定义，其实很多我们日常使用的语法都符合这个条件，比如对类的静态扩展方法。

传统的装饰者模式有比较明显的缺点：

1. 可能产生 “装饰器膨胀”，增加系统理解成本。装饰器模式的核心是通过 “层层嵌套” 实现功能叠加，但每增加一个细粒度的扩展功能，就需要新增一个装饰器类。当扩展需求较多时，会导致系统中出现大量细粒度装饰器，增加代码量和理解成本。

2. 嵌套层级过深时，调试和排查问题困难

因此个人认为不必局限于书中提供的实现方式，重点是基于实际情况，既不过度设计，又能在变化的业务中找出不变的点进行抽象，切实的提高系统代码的可维护性和可扩展性。