《大话设计模式》笔记——装饰模式

装饰模式是动态地给一个对象添加一些额外的功能的一种方式，就增加功能而言，装饰模式比生成子类更加灵活。

装饰模式的结构图如下：

Component类：被装饰的抽象类，也可以理解为承担核心职责的主类。主要负责一些共用的、核心的功能的实现。

ConcreteComponent类：一个具体的被装饰对象。

Decorator类：装饰抽象类，通过setComponent绑定被装饰对象。需要重写被装饰对象的Operation()，实际执行的是Component的Operation()。

ConcreteDecorator类：一个具体的装饰对象，在这里实现需要增加的具体功能。在重写Operation()时需要注意执行其绑定的Component的Operation()，再加上额外增加的功能。

在装饰模式中利用setComponent对对象进行包装，从而将装饰功能与类的主要功能分离开，在不改动原有功能实现的情况下实现了新功能的扩展，这种模式的可扩展性很强，且有效的降低了主类的复杂度，其优势在一个拥有较多特定附加功能的类中格外明显。

以一个场景为例。某家店正在销售汉堡，在汉堡中可以加入牛肉饼、鸡蛋、生菜、西红柿、芝士等材料，顾客可以选择只加鸡蛋或者选择加入鸡蛋和芝士并希望鸡蛋在下面。由于顾客加料的数量没有限制，可以加的料有很多，此时若是只用一个类去实现，是没法实现顾客的需求的，排列组合太多了，如果汉堡店打算不卖或者某种食材也会非常麻烦。但是用装饰模式就可以解决这个问题，可以将只含面包坯的汉堡作为Component，每一种加料作为ConcreteDecorator，那么加入鸡蛋和芝士并希望鸡蛋在下面的汉堡就可以表示为先用鸡蛋装饰面包坯，再用芝士装饰鸡蛋装饰面包坯的汉堡即可。

由此可见，装饰模式的增加功能是非常灵活的。不过，装饰模式也是有弊端的，它的多层装饰造成了程序复杂度的提高。首先，多层装饰的装饰顺序很重要，如果两个装饰功能之间存在依赖性，那一旦顺序错了将会造成严重的问题；其次，调试复杂，假设现在有很多层装饰，出了bug就需要一层层的检查，最后发现是最里层出了问题，那这耗费的工作量就太大了。