各种设计模式--应用场景：
装饰器模式：
1、类继承会导致类的膨胀，这时候装饰器就派上用场了
责任链模式：
1、ifelse 用责任链来实现
状态模式：
1、ifelse
适配器模式：目的是在原来代码的基础上面，增加一些修饰的东西。
1、订单信息，比如增加了活动了之后，返回结果中要包含活动信息，在原来代码的基础上面给返回的Bean里面增加一些活动信息。
代理模式：
比如吧，我有一个业务，同时要调用外部系统的http实现的接口和webservice实现的接口，可以做一个代理类， 代理webservice接口和http接口， 代理类帮我判断该用哪个， 我直接调用代理类就行了。代理类专门屏蔽后面的接口或者协议。
模板方法模式：
1、比如订单的下单还有退款操作，都需要同时判断使用的金额和红包。
2、支付的时候，调用不同的支付方式，都需要去做判断。
策略模式：
策略模式和装饰器模式区别：
策略模式偏向于对实现方法或策略的封装，调用者不需要考虑具体实现，只要指定使用的策略即可。
装饰器模式一般用于需要对功能进行扩展的场合，每一种装饰都是一种扩展或增强。
看起来两个模式好像没有必然的联系，但是在实际使用过程中,发现了一个让我困惑的地方。
先看一个典型的场景：
商场对客户打折，老客户8折，新客户9折，新客户购物满3000，打8.5折
对这个基本场景，一般给的经典模式是策略模式，很多书也以这个作为策略模式的的经典案例。
但是，如果我把每一种折扣看作是一种对原有价格的装饰，这个场景也是可以用装饰器模式实现的。
两个模式都需要花费一些代码去判断策略或装饰器的类型，而且实现难度也旗鼓相当。
我用两种模式都实现了相同的功能，但是却没有发现明显的区别，不知道大家对这两个模式怎么看，
欢迎讨论。
策略模式更倾向是N选1的模式，也即根据条件选择相应的算法，但各种算法是互斥的，比如：团体客户和个人客户的优惠政策必然是非此即彼的；
装饰模式是在主体逻辑的基础上的附加逻辑，比如，个人客户有的属于同城客户，支持送货上门。
谢谢您的回复，如果按照策略模式，每一种打折方案是一种策略，而且只能选择一个，这是没有问题的。
按照装饰模式，每一种折扣都是在购买金额上的附加，在没有折上折或者送货上门这些附加值的时候，我感觉装饰模式也是实用的，当然，当折上折和送货这种附加体现的时候，装饰起的模式就体现去来了。
所以，我感觉在当前描述的问题中，这两个模式应该都可以很恰当的实现需求，但是没感觉到本质的区别。
于是就有些困惑了，看了您的总结，我感觉自己有点钻牛角了。
如果这个场景新增附加需求，比如新增vip客户，那么策略模式就比较合适了。
但是如果进行折上折或者送货上门这类附加需求，很明显装饰模式会更好一些了。
看来具体的模式还得根据实际需求确定，不能死搬硬套。
尽管楼主可以使用两种模式实现自己说的场景，但是两者还是有本质的区别。
策略模式，已经说的很清楚， 就不多说了。
装饰模式是主题逻辑的基础上的加强。可以看看JAVA IO的设计。
就像楼上说的， 如果客户购买满5000， 不只可以享受7折优惠， 还可以送货上门。
这里有两项功能： 1） 7折优惠， 2）送货上门
如果使用策略模式， 我们势必把两项功能都写在一个策略的实现类里面。
假使现在有新的场景出现，就是老客户购买满3000， 也享受送货上门。（或者说这里面的还蕴藏一些其他的优惠，比如说返券等等）
难道我们又把这些功能添加到我们的策略里面， 这样代码就很生硬而且不容易修改。
但是使用装饰模式就不一样，装饰模式能动态的给对象增加特有的功能。 比如说IO里面可以添加Buffer的功能。 同样在我们的场景里面，我们也可以将送货上门、返券等也动态的增强， new 送货上门（new 返券（））...., 这样子就很灵活了。
策略实现可能类似：
do7折()；
do送货上门（)；
do返券（）
装饰的实现可能了类似：
new 7折（ new 送货上门（new 返券（）））， 能随意组合；
所有的优惠都享受上了， 看上去还是爽一点。
其实装饰模式， 还是更符合设计的一条原则： 少继承， 多组合