介绍
装饰者模式动态地将责任对象，来扩展功能，装饰的继承提供了更灵活的选择。

思维导图






有这样一个项目做一个餐厅的预订系统。这是结构的原代码。前面有许多饮料类的继承问题现在是牛奶的价格上涨，那么所有相关的类，我们必须调整，如牛奶、sugarandmilk类，这个类有很多，我们需要修改一个类的方法――开发商一次做这样的事情，要疯了！所以我们必须改变现有的结构。下面的图表是一个简单的图表，实际的图表不是那么简单。







设计问题：

1，爆炸的种类很多，很难维持。
2，整个设计是乏味的；
3，基类中的新函数不能用于子类中。
有很多方法可以重用类方法，比如继承、组合和委托。为什么它总是用来继承我想Zend框架有这样的习惯，太！每一次你寻找相应的方法，你去了所有的时间。-题外话！！！！
后来，经过小组研究，我们决定起草基础课。例如，我们把咖啡分成一个单独的类别，其他的咖啡，如牛奶咖啡和甜咖啡。我们只把材料包装成一个班。
改进后的设计：




详细的
1对于饮料，我们直接继承饮料类，直接将报价写在饮料类别中；
2，对于一些需要添加调味品的特殊饮料，我们做一个累计操作。例如，我想要一杯牛奶咖啡，总的价格是咖啡和牛奶价格。
三.很容易知道这种不同饮料的价格。
代码
复制代码代码如下所示：
< PHP
抽象类饮料{
公共_name美元；
抽象公共功能成本（）；
}
做装饰类
类咖啡延伸饮料{
公共功能__construct（）{
美元-> _name = 'coffee；
}
公共功能成本（）{
返回1；
}
}
以下三类观赏类
condimentdecorator延伸类饮料{
公共功能__construct（）{
美元-> _name = 'condiment；
}
公共功能成本（）{
返回0.1；
}
}
类奶延伸condimentdecorator {
公共_beverage美元；
公共功能__construct（$饮料）{
美元-> _name =乳症；
如果（合饮料是饮料）{
美元-> _beverage = $饮料；
}其他
退出（'failure）；
}
公共功能成本（）{
返回_beverage美元-> ->成本（）+ 0.2；
}
}
类糖延伸condimentdecorator {
公共_beverage美元；
公共功能__construct（$饮料）{
美元-> _name = 'sugar；
如果（合饮料是饮料）{
美元-> _beverage = $饮料；
其他{ }
退出（'failure）；
}
}
公共功能成本（）{
返回_beverage美元-> ->成本（）+ 0.2；
}
}
测试
1。喝杯咖啡
咖啡=新咖啡（）；
2。加一点牛奶
咖啡=新牛奶（咖啡）；
3。加糖
咖啡=新糖（咖啡）；
printf（咖啡总：% 0.2f元

总结
1。装饰师（牛奶）和装饰师（咖啡）必须是同一类型的。
2。添加行为：当装饰器和组件组合时，它将添加新的行为。
题外话：
1。使用继承设计子类行为是在编译时静态确定的，所有子类将继承相同的行为。例如，Laozi想学习一些技巧，看看你的孩子能打太极拳。老子只需要继承你。Lao Tzu也会做台继权。嘿嘿，当Lao Tzu成为你的儿子，似乎继承的成本钱。
2。组合，我们可以扩展对象的行为，并扩大在运行时动态的。使用的结合，我们可以随时添加的方法，我们不想在下课时间对象，在不改变现有的代码。例如，Lao Tzu现在没有内力，吸收功率法，僧侣的内力，修女，牧师（行为对象）被吸入了战斗（在运行时），Lao Tzu总是能够利用不同的内力，也不能随意吸收内力，否则你将进入火！
3。类别应该对扩展开放，修改应该关闭。如果我们的每个部分都是用装饰器模式设计的，这对整个框架有点浪费，并且增加了代码的难度。什么时候使用这个模型我们通常在经常变化的地方使用，所以我们怎么知道哪些地方经常变化呢这需要我们的经验和你对这个行业的理解，建议你在平时多看一些例子。
4。装饰图案是为注入弹性而设计的，但同时也会在设计中加入大量的小类，这偶尔会使其他人不容易理解设计。
5。在使用装饰模式时，插入的装饰应该特别小心，因为装饰模式取决于特定类型（饮料）。
6。为了更好地利用装饰模式，我们也必须与工厂模式和发电机模式合作，但今天只有装饰模式。想知道更多，请听下一次。
参考文献：头一个设计模式