【大话】策略模式

起因：

小菜在做一个商场收银软件，里面有很多的商场活动，进行打折或者返利活动的情况，小菜自以为这个项目非常简单，但是大鸟却不是这么认为的，在他看来小菜写得代码还有很多的提升空间。

第一次改进：

运用简单工厂模式：由于面向对象的基础，我们必须要学会抽象。所以小菜把现金收费的类抽象成一个抽象类，然后每一个具体收费方式作为一个类来继承这个抽象类，并在每个具体的类中重写收取现金的方法。然后再写一个现金收取工厂类，用于判断商场都是在进行哪种活动，并根据活动调用相应的算法方法。这样只需要在客户端判断并选择相应的打折方式并对应的调用相应类中的方法就可以了。

缺点：应用简单工厂虽然可以解决这个问题，但是如果商场要增加打折的方式的话，就得每次都去修改程序的代码，这就给代码的维护带来了一定的麻烦，所以大鸟又要求小菜进行修改。

第二次修改：

运用策略模式：策略模式定义了算法家族，，分别把其封装起来，让他们之间可以相互替换，让算法的改变，不会影响到使用算法的客户。这也是我们面向对象的一种重要思维--- 封装变化点。

我们可以考虑把算法抽象成一个类，里面只定义一个抽象的算法方法。而这个算法怎么实现，要靠子类的重写，这些子类就是具体算法类。定义一个算法类后我们可以考虑一下我们在客户端不论使用哪个算法都得先将这些算法实例化然后再运用它的具体方法。这些是一部分的重复的代码，那么重复的代码我们就又可以抽象出一个使用算法类的类（Context类），这个类专门用来传入具体的收费策略，并且根据策略的不同来计算不同的结果（调用抽象算法类的方法）。这样根据客户端的判断，直接调用Context类的方法就可以计算结果。这些分析的结果就可以用下面这一幅图展示。

由于第二次的修改必须得在客户端进行判断，来决定用哪一个算法去实现。这样，如果超市增加一种打折方式的话，会必须得修改客户端和具体算法类的代码才可以。这种每次都得修改客户端的方法是极其不方便的，我们必须得尽量避免。

第三次修改：

策略模式和简单工厂结合：我们可以把判断用哪一个收费策略的分支语句放到Context类中，这样就做到了简单工厂的应用，而其他的类不变还是应用的策略模式。客户端方面：可以根据下拉菜单选择的超市促销方式而有针对性的进行Context类中方法的调用。

 

由此，就既做到了算法的改变不会影响客户端的应用。又做到了各种算法和使用算法类之间的耦合。其实不仅是只针对算法，在现实生活中只要碰到需要在不同时间应用不同的业务规则，就可以使用策略模式。