一、引子—星巴兹咖啡
Beverage是抽象类，cost()是抽象方法，每个子类需要定义自己的实现。
但是购买咖啡时，需要加入各种调料：Steadmed Milk、Soy、Mocha等，加入不同的调料，收取不同的费用，所以订单系统需要考虑调料部分。
{dy}个尝试：
子类大爆炸，HouseBlend+SteadMed Milk、HouseBlend+ Soy、HouseBlend+Mocha、HouseBlend+SteadMed Milk+Soy、DarkRoast+Milk、Dark+soy+Mocha……得出不同的饮料子类+调料的价格。
问题：如果调料价格上涨，新增了一种调料，那会造成修改。
违反了2个原则。
第二个尝试：
利用实例变量和继承，就可以追踪这些调料。
先从Beverage基类下手，加上实例变量代表施肥加上调料（Soy，Milk，Mocha……）
基类Beverage的cost()不再是抽象方法，我们提供了cost()的实现，让他计算要加入各种饮料的调料价钱。子类仍将覆盖cost()，但是会调用超类的cost()，计算出基本饮料加上调料的价钱。
基类中加入了取得和设置调料的布尔值函数。(hasMilk和setMilk之类。)
每个饮料子类的cost()方法需要计算该饮料的价钱，然后通过调用超类的cost()实现，加入调料的价钱。
这种设计减少了类的个数，但是当需求或因素改变时会影响设计。
1.调料价格的改变会使我们更改现有代码；
2.一旦出现新调料，我们就要加上新的方法，并改变超类中的cos()方法；
3.以后可能开发出新饮料，对这些饮料而言（例如冰茶），某些调料可能并不适合，但是这个设计方案中，Tea子类仍然将继承那些不适合的方法，例如haSoy（茶+豆浆）
4.顾客想要双倍Mocha，怎末办？
二、开发--关闭原则
对扩展开放，对修改关闭。
如何让设计的每个部分都遵循开放—关闭原则？
通常办不到。要让OO设计同时具备开放和关闭性，又不修改现有的代码，需要花费很多时间和努力。遵循开放—关闭原则，通常会引入新的抽象层次，增加代码的复杂度。你只需要把注意力集中在设计中最有可能改变的地方，然后运用开放—关闭原则。
三、认识装饰者模式
我们已经了解了利用继承无法xx解决的问题：类数量爆炸、设计死板、以及基类加入的新功能并不能适用与所有子类。
这里采用不一样的做法：以饮料为主体，然后在运行时以调料来“装饰”饮料。
DarkRoast层：DarkRoast继承自Beverage，且有一个用来就是饮料价钱 cost()方法。
Mocha层：Mocha对象是一个装饰者，它的类型“反映”了它所装饰的对象。所谓“反映”指2者类型一致。所有，Mocha也有一个cost()方法。通过多态，也可以把Mocha所包裹的任何Beverage当成Beverage（因为Mocha是Beverage的子类型）
Whip层：Whip是一个装饰者，所有它也反映了DarkRoast类型，并包括一个cost()方法。所以，被Mocha和Whip包起来的DarkRoast对象仍然是一个Beverage，仍然可以具有DarkRoast的一切行为，包括调用它的cost()方法。
{zh1}，是顾客结算的时候。如下图所示：
原创 设计模式系列之四：装饰者模式(Decorator Pattern) 收藏
一、引子—星巴兹咖啡
Beverage是抽象类，cost()是抽象方法，每个子类需要定义自己的实现。
但是购买咖啡时，需要加入各种调料：Steadmed Milk、Soy、Mocha等，加入不同的调料，收取不同的费用，所以订单系统需要考虑调料部分。
{dy}个尝试：
子类大爆炸，HouseBlend+SteadMed Milk、HouseBlend+ Soy、HouseBlend+Mocha、HouseBlend+SteadMed Milk+Soy、DarkRoast+Milk、Dark+soy+Mocha……得出不同的饮料子类+调料的价格。
问题：如果调料价格上涨，新增了一种调料，那会造成修改。
违反了2个原则。
第二个尝试：
利用实例变量和继承，就可以追踪这些调料。
先从Beverage基类下手，加上实例变量代表施肥加上调料（Soy，Milk，Mocha……）
基类Beverage的cost()不再是抽象方法，我们提供了cost()的实现，让他计算要加入各种饮料的调料价钱。子类仍将覆盖cost()，但是会调用超类的cost()，计算出基本饮料加上调料的价钱。
基类中加入了取得和设置调料的布尔值函数。(hasMilk和setMilk之类。)
每个饮料子类的cost()方法需要计算该饮料的价钱，然后通过调用超类的cost()实现，加入调料的价钱。
这种设计减少了类的个数，但是当需求或因素改变时会影响设计。
1.调料价格的改变会使我们更改现有代码；
2.一旦出现新调料，我们就要加上新的方法，并改变超类中的cos()方法；
3.以后可能开发出新饮料，对这些饮料而言（例如冰茶），某些调料可能并不适合，但是这个设计方案中，Tea子类仍然将继承那些不适合的方法，例如haSoy（茶+豆浆）
4.顾客想要双倍Mocha，怎末办？
二、开发--关闭原则
对扩展开放，对修改关闭。
如何让设计的每个部分都遵循开放—关闭原则？
通常办不到。要让OO设计同时具备开放和关闭性，又不修改现有的代码，需要花费很多时间和努力。遵循开放—关闭原则，通常会引入新的抽象层次，增加代码的复杂度。你只需要把注意力集中在设计中最有可能改变的地方，然后运用开放—关闭原则。
三、认识装饰者模式
我们已经了解了利用继承无法xx解决的问题：类数量爆炸、设计死板、以及基类加入的新功能并不能适用与所有子类。
这里采用不一样的做法：以饮料为主体，然后在运行时以调料来“装饰”饮料。
DarkRoast层：DarkRoast继承自Beverage，且有一个用来就是饮料价钱 cost()方法。
Mocha层：Mocha对象是一个装饰者，它的类型“反映”了它所装饰的对象。所谓“反映”指2者类型一致。所有，Mocha也有一个cost()方法。通过多态，也可以把Mocha所包裹的任何Beverage当成Beverage（因为Mocha是Beverage的子类型）
Whip层：Whip是一个装饰者，所有它也反映了DarkRoast类型，并包括一个cost()方法。所以，被Mocha和Whip包起来的DarkRoast对象仍然是一个Beverage，仍然可以具有DarkRoast的一切行为，包括调用它的cost()方法。
{zh1}，是顾客结算的时候。如下图所示：
目前知道的：
1.装饰者和被装饰者有相同的超类型。
2.可以用一个或多个装饰者包装一个对象。
3.既然装饰者和被装饰者对象有相同的超类型，所以在任何需要原始对象（被包装）的场合，可以用装饰过的对象代替它。
4.装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的。
5.对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。
四、定义和类图
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
类图
结合装饰者模式类图画出星巴兹饮料的的机构
五、源代码
六、补充说明
问：如果将代码针对特定种类的具体组件（如HouseBlend），做一些特俗的事（如打折），我担心这样的设计是否恰当。因为一旦用装饰者包装HouseBlend，就会造成类型改变。
答：确实这样，如果你把代码写成依赖与具体的组件类型，那么装饰者就会导致程序出问题。只有在针对抽象组件类型编程时，才不会因为装饰者而受到影响。但是，如果的确针对特定的具体组件编程，就应该重新思考你的应用架构，以及装饰者是否合适。
装饰者通常用其他类似与工厂或生成器这样的模式创建，具体的组件和装饰者的创建过程会“封装的很好”。
装饰者模式能为设计注入弹性，但是会加入大量小类，偶尔会导致不易理解。
七、设计箱内的工具
OO原则
封装变化；
多用组合，少用继承；
针对接口编程，不针对实现编程；
为交互对象之间的松耦合设计而努力；
对扩展开发，对修改关闭；
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案
要点
继承属于扩展形式之一，但不一定是达到弹性设计的{zj0}方案；
在设计中，应该允许行为可以被扩展，而无须修改现有的代码；
组合和委托可用于在运行时动态地加上新的行为；
除了继承，装饰者也可以扩展行为；
装饰者意味着一群装饰者类，这些类用来包装具体组件；
装饰者类反映吃被装饰的组件的类型（他们具有相同的类型，都经过接口或继承实现）；
装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的；
你可以用无数个装饰者包装一个组件；
装饰者一般对组件的客户是透明的，除非客户程序依赖组件的具体类型。
装饰者会导致设计中出现很多小对象，过度使用，会让程序变得复杂。
Beverage是抽象类，cost()是抽象方法，每个子类需要定义自己的实现。
但是购买咖啡时，需要加入各种调料：Steadmed Milk、Soy、Mocha等，加入不同的调料，收取不同的费用，所以订单系统需要考虑调料部分。
{dy}个尝试：
子类大爆炸，HouseBlend+SteadMed Milk、HouseBlend+ Soy、HouseBlend+Mocha、HouseBlend+SteadMed Milk+Soy、DarkRoast+Milk、Dark+soy+Mocha……得出不同的饮料子类+调料的价格。
问题：如果调料价格上涨，新增了一种调料，那会造成修改。
违反了2个原则。
第二个尝试：
利用实例变量和继承，就可以追踪这些调料。
先从Beverage基类下手，加上实例变量代表施肥加上调料（Soy，Milk，Mocha……）
基类Beverage的cost()不再是抽象方法，我们提供了cost()的实现，让他计算要加入各种饮料的调料价钱。子类仍将覆盖cost()，但是会调用超类的cost()，计算出基本饮料加上调料的价钱。
基类中加入了取得和设置调料的布尔值函数。(hasMilk和setMilk之类。)
每个饮料子类的cost()方法需要计算该饮料的价钱，然后通过调用超类的cost()实现，加入调料的价钱。
这种设计减少了类的个数，但是当需求或因素改变时会影响设计。
1.调料价格的改变会使我们更改现有代码；
2.一旦出现新调料，我们就要加上新的方法，并改变超类中的cos()方法；
3.以后可能开发出新饮料，对这些饮料而言（例如冰茶），某些调料可能并不适合，但是这个设计方案中，Tea子类仍然将继承那些不适合的方法，例如haSoy（茶+豆浆）
4.顾客想要双倍Mocha，怎末办？
二、开发--关闭原则
对扩展开放，对修改关闭。
如何让设计的每个部分都遵循开放—关闭原则？
通常办不到。要让OO设计同时具备开放和关闭性，又不修改现有的代码，需要花费很多时间和努力。遵循开放—关闭原则，通常会引入新的抽象层次，增加代码的复杂度。你只需要把注意力集中在设计中最有可能改变的地方，然后运用开放—关闭原则。
三、认识装饰者模式
我们已经了解了利用继承无法xx解决的问题：类数量爆炸、设计死板、以及基类加入的新功能并不能适用与所有子类。
这里采用不一样的做法：以饮料为主体，然后在运行时以调料来“装饰”饮料。
DarkRoast层：DarkRoast继承自Beverage，且有一个用来就是饮料价钱 cost()方法。
Mocha层：Mocha对象是一个装饰者，它的类型“反映”了它所装饰的对象。所谓“反映”指2者类型一致。所有，Mocha也有一个cost()方法。通过多态，也可以把Mocha所包裹的任何Beverage当成Beverage（因为Mocha是Beverage的子类型）
Whip层：Whip是一个装饰者，所有它也反映了DarkRoast类型，并包括一个cost()方法。所以，被Mocha和Whip包起来的DarkRoast对象仍然是一个Beverage，仍然可以具有DarkRoast的一切行为，包括调用它的cost()方法。
{zh1}，是顾客结算的时候。如下图所示：
原创 设计模式系列之四：装饰者模式(Decorator Pattern) 收藏
一、引子—星巴兹咖啡
Beverage是抽象类，cost()是抽象方法，每个子类需要定义自己的实现。
但是购买咖啡时，需要加入各种调料：Steadmed Milk、Soy、Mocha等，加入不同的调料，收取不同的费用，所以订单系统需要考虑调料部分。
{dy}个尝试：
子类大爆炸，HouseBlend+SteadMed Milk、HouseBlend+ Soy、HouseBlend+Mocha、HouseBlend+SteadMed Milk+Soy、DarkRoast+Milk、Dark+soy+Mocha……得出不同的饮料子类+调料的价格。
问题：如果调料价格上涨，新增了一种调料，那会造成修改。
违反了2个原则。
第二个尝试：
利用实例变量和继承，就可以追踪这些调料。
先从Beverage基类下手，加上实例变量代表施肥加上调料（Soy，Milk，Mocha……）
基类Beverage的cost()不再是抽象方法，我们提供了cost()的实现，让他计算要加入各种饮料的调料价钱。子类仍将覆盖cost()，但是会调用超类的cost()，计算出基本饮料加上调料的价钱。
基类中加入了取得和设置调料的布尔值函数。(hasMilk和setMilk之类。)
每个饮料子类的cost()方法需要计算该饮料的价钱，然后通过调用超类的cost()实现，加入调料的价钱。
这种设计减少了类的个数，但是当需求或因素改变时会影响设计。
1.调料价格的改变会使我们更改现有代码；
2.一旦出现新调料，我们就要加上新的方法，并改变超类中的cos()方法；
3.以后可能开发出新饮料，对这些饮料而言（例如冰茶），某些调料可能并不适合，但是这个设计方案中，Tea子类仍然将继承那些不适合的方法，例如haSoy（茶+豆浆）
4.顾客想要双倍Mocha，怎末办？
二、开发--关闭原则
对扩展开放，对修改关闭。
如何让设计的每个部分都遵循开放—关闭原则？
通常办不到。要让OO设计同时具备开放和关闭性，又不修改现有的代码，需要花费很多时间和努力。遵循开放—关闭原则，通常会引入新的抽象层次，增加代码的复杂度。你只需要把注意力集中在设计中最有可能改变的地方，然后运用开放—关闭原则。
三、认识装饰者模式
我们已经了解了利用继承无法xx解决的问题：类数量爆炸、设计死板、以及基类加入的新功能并不能适用与所有子类。
这里采用不一样的做法：以饮料为主体，然后在运行时以调料来“装饰”饮料。
DarkRoast层：DarkRoast继承自Beverage，且有一个用来就是饮料价钱 cost()方法。
Mocha层：Mocha对象是一个装饰者，它的类型“反映”了它所装饰的对象。所谓“反映”指2者类型一致。所有，Mocha也有一个cost()方法。通过多态，也可以把Mocha所包裹的任何Beverage当成Beverage（因为Mocha是Beverage的子类型）
Whip层：Whip是一个装饰者，所有它也反映了DarkRoast类型，并包括一个cost()方法。所以，被Mocha和Whip包起来的DarkRoast对象仍然是一个Beverage，仍然可以具有DarkRoast的一切行为，包括调用它的cost()方法。
{zh1}，是顾客结算的时候。如下图所示：
目前知道的：
1.装饰者和被装饰者有相同的超类型。
2.可以用一个或多个装饰者包装一个对象。
3.既然装饰者和被装饰者对象有相同的超类型，所以在任何需要原始对象（被包装）的场合，可以用装饰过的对象代替它。
4.装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的。
5.对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。
四、定义和类图
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
类图
结合装饰者模式类图画出星巴兹饮料的的机构
五、源代码
Beverage.cs
public abstract class Beverage
{
string description = "Unknown Beverage";
public virtual string GetDescription()
{
return description;
}
public abstract double Cost();
}
Expresso.cs
class Expresso:Beverage
{
public Expresso() { }
public override double Cost()
{
return 1.99;
}
public override string GetDescription()
{
return "Expresso";
}
}
HouseBlend.cs
class HouseBlend:Beverage
{
public HouseBlend() { }
public override double Cost()
{
return 0.89;
}
public override string GetDescription()
{
return "House Blend Coffe";
}
}
CondimentDecorator.cs
public abstract class CondimentDecorator:Beverage
{
public CondimentDecorator() { }
}
Mocha.cs
class Mocha:CondimentDecorator
{
Beverage berverage;
public Mocha(Beverage berverage)
{
this.berverage = berverage;
}
public override string GetDescription()
{
return berverage.GetDescription() + ", Mocha";
}
public override double Cost()
{
return 0.2 + berverage.Cost();
}
}
Soy.cs
class Soy:CondimentDecorator
{
Beverage beverage;
public Soy(Beverage beverage)
{
this.beverage = beverage;
}
public override string GetDescription()
{
return beverage.GetDescription()+", Soy";
}
public override double Cost()
{
return 0.15 + beverage.Cost();
}
}
SteamedMilk.cs
class SteamedMilk:Beverage
{
Beverage beverage;
public SteamedMilk(Beverage beverage)
{
this.beverage = beverage;
}
public override string GetDescription()
{
return beverage.GetDescription()+", Steamed Milk";
}
public override double Cost()
{
return 0.1 + beverage.Cost();
}
}
Program.cs
class Program
{
static void Main(string[] args)
{
Beverage berverage1 = new HouseBlend();
System.Console.WriteLine(berverage1.GetDescription() + "元"
+ berverage1.Cost().ToString());
Beverage berverage2 = new Expresso();
berverage2 = new Mocha(berverage2);
berverage2 = new Mocha(berverage2);
berverage2 = new Soy(berverage2);
System.Console.WriteLine(berverage2.GetDescription() + "元"
+ berverage2.Cost().ToString());
}
}
六、补充说明
问：如果将代码针对特定种类的具体组件（如HouseBlend），做一些特俗的事（如打折），我担心这样的设计是否恰当。因为一旦用装饰者包装HouseBlend，就会造成类型改变。
答：确实这样，如果你把代码写成依赖与具体的组件类型，那么装饰者就会导致程序出问题。只有在针对抽象组件类型编程时，才不会因为装饰者而受到影响。但是，如果的确针对特定的具体组件编程，就应该重新思考你的应用架构，以及装饰者是否合适。
装饰者通常用其他类似与工厂或生成器这样的模式创建，具体的组件和装饰者的创建过程会“封装的很好”。
装饰者模式能为设计注入弹性，但是会加入大量小类，偶尔会导致不易理解。
七、设计箱内的工具
OO原则
封装变化；
多用组合，少用继承；
针对接口编程，不针对实现编程；
为交互对象之间的松耦合设计而努力；
对扩展开发，对修改关闭；
装饰者模式动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案
要点
继承属于扩展形式之一，但不一定是达到弹性设计的{zj0}方案；
在设计中，应该允许行为可以被扩展，而无须修改现有的代码；
组合和委托可用于在运行时动态地加上新的行为；
除了继承，装饰者也可以扩展行为；
装饰者意味着一群装饰者类，这些类用来包装具体组件；
装饰者类反映吃被装饰的组件的类型（他们具有相同的类型，都经过接口或继承实现）；
装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的；
你可以用无数个装饰者包装一个组件；
装饰者一般对组件的客户是透明的，除非客户程序依赖组件的具体类型。
装饰者会导致设计中出现很多小对象，过度使用，会让程序变得复杂。
