我们的目标是实现更大的弹性和更好的可维护性的设计。
运行时扩展，远比编译时期的继承威力大。
对于继承存在的继承滥用问题，装饰者模式给爱用继承的人了一个全新的设计眼界。
一旦你熟悉了装饰的技巧，你将能够在不修改任何底层代码的情况下，给你的（或别人的）对象赋予新的职责。
1）首先，我们要设计的是星巴兹咖啡店的各饮品名目
起初的类设计：
当人们购买咖啡时，可以要求加入各种调料，而我们需要根据调料的不同，对售卖的咖啡进行计价。
所以我们可以这样进行处理：
无疑，这种滥用继承的设计结果使我们所不能接受的。
当其中一种调料的价格变动或者再加入一种新的调料时，我们会发现我们进行维护的成本是巨大的。
2）现在我们考虑第二种设计实现。对于上述步骤中的继承类爆炸的状态，我们可以不设计这么多类，而是利用实例变量和继承，就可以追踪这些调料。
这样我们所实现的类就比1）中少了很多。似乎这是一个可行的解决办法，但是，又似乎隐隐存在着些问题！
我们知道，虽然继承的威力强大，但是它不总是能够实现最有弹性和最好维护的设计。
为了不通过“继承”而实现代码复用，我们可以利用组合（composition）和委托（delegation），使得我们的程序可以在运行时具有继承行为的效果。
利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展到对象的行为，就可以在运行时动态地进行扩展。
我们可以利用这个技巧把多个新职责，甚至是设计超类时还没有想到的职责加载对象上，而且重要的是，我们不用修改原来的代码。因为我们没有改变现有代码，那么引进bug或产证意外副作用的机会将大幅度减少。
此时，我们介绍一下新的设计原则：
我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。
这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。
但是在选择需要被扩展的代码部分时要小心。每个地方都采用开放—关闭原则，是一种浪费，也没有必要，还会导致代码变得复杂且难以理解。
3）让我们来看一看装饰者模式的大概概念
归纳一下：
4）定义装饰者模式
有没有发现什么吊诡的地方，不是说好的不用“继承”么？还以为会用“组合”代替“继承”，没想到还是得用“继承”。
在装饰者模式中，的确是如此，但是这么做的重点在于装饰者和被装饰者必须是一样的类型，也就是有共同的超类，这是相当关键的地方。在这里，我们利用继承达到“类型匹配”，而不是利用继承获得“行为”。
那么“行为”从哪里来？我们在将装饰者与组件组合时，就是在加入新的行为。所得到的新行为，并不是继承自超类，而是由组合对象得来的。
所以，“行为”来自装饰者和基础组件，或与其他装饰者之间的组合关系。而且因为使用对象组合，可以把所有饮料和调料更有弹性地加以混合与匹配。
那么在这个例子中为什么不把Beverage类设计成一个接口，而是设计成一个抽象类呢？
因为在本例子的题目中，Beverage就已经是一个“抽象类”了，通常装饰者模式是采用抽象类，但是在Java中可以使用接口。尽管如此，通常我们都努力避免修改现有的代码，所以，如果抽象类运作得好好的，还是别去修改它了，我们不妨“懒”一下。
5）具体实现本例中的代码
6）真实世界的装饰者：Java I/O
7）小结
装饰者模式可以为设计注入弹性，但是也会在设计中加入大量的小类。这个可以配合工厂模式（Factory）和生成器（Builder）模式使用，对装饰者模式进行优化改进。
OO基础：
OO原则：
OO模式：
要点：
参考书目：《Head First 设计模式》
原文地址：https://www.cnblogs.com/dudududu/p/9120977.html
