各种设计模式--应用场景:
装饰器模式:
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 返券())), 能随意组合;
所有的优惠都享受上了, 看上去还是爽一点。
其实装饰模式, 还是更符合设计的一条原则: 少继承, 多组合