目前对装饰者模式产生的原因理解如下：
若以人穿衣服，或是饮料店对饮料加料为例，人跟饮料可以是最上层的父类别
衣服可以有很多种，饮料要加的料也可以有很多种，若是以继承的方式来给人穿衣服
或是给饮料加料，这样的话：
人+一种衣服是一种子类别，饮料+一种料也是一种子类别。
这样的话很多种衣服很多种料，就会有很多种子类别。
更不要说很多种衣服、很多种料各自还可以组合出不同子类别。
所以很明显，子类别数量会过于庞大。
而且人+一种衣服、饮料+一种料，按照逻辑，衣服跟料都是可选择的，顺序不固定的，
若用继承方式去扩充人和饮料的话，那就是把穿衣服跟加料的顺序写死。这就完全
不符合人类穿衣或给饮料加料的逻辑，也就是说完全不合理。
这是一个原因。
另一个原因，以麦当劳主餐配副餐，组成套餐为例。主餐配副餐形成套餐，
看似可以用继承方式来描述，也就是主餐为父类别，套餐继承主餐类别并加上副餐，
形成子类别。但是
主餐往往不只一种，这样的话变成有多种主餐，套餐要继承主餐就会变成是多重继承。
因此在某些需求下，会变成多重继承，这是Java程式必须避免的现象。
再来，若是坚持要以继承来实作以上的例子，继承可能会有很多层，例如饮料加了
很多料，其实就是子类别有好几层，下一层类别都包含了上一层类别，这样的话，
若是要计算“加了很多料的饮料”的价格，计算的method必须层层呼叫到最上层的类别，
取出原始饮料的价格后，又层层返回到最下层的，加了很多料的类别，这样才能计算出
“加了很多料的饮料”的价格，也就是说类别之间相依性很高，而相依性高正好也是
Java程式必须避免的问题。