商场有打折、满减、积分、送卷等促销手段，可以用简单工厂模式创建一个收费对象生产工厂，分门别类的创建不同的促销实例，然后switch判断具体实例化哪个促销实例。但是商场可能经常性的更改各种促销策略，使用每次改动都要维护改动对应的工厂，以至于代码需要重新编译部署，这是很糟糕的处理方式，所以它不是最好的办法。面对算法的时常变动，会有更好的办法。<br /> **策略模式：它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。**<br /><br /> 不同的促销手段都是一些算法，用工厂来生成算法对象这没有错，但算法本身只是一种策略，最重要的是这些算法是随时都可能互相替换的，这就是变化点。封装变化点是面向对象一直很重要的思维方式。<br /> 但直接使用基本的策略模式会导致在客户端上switch判断使用哪个策略，可以使用策略与简单工厂的结合消除，还可以让客户端只认一个类CashContex。但这依然不够完美，如果要增加一种算法就需要改动switch中的算法，可以使用反射。<br /> 策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合。<br /> 策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。如：无论是何种策略最后都是计算费用的结果 。<br /> 策略模式还可以简化单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
若有收获，就点个赞吧
0 人点赞
