设计模式入门篇-策略模式

情境预设：

某互联网公司想做一款财务系统，并服务于公司A、B、C，公司ABC都有着共同的需求–进行成本、收支、支出的统计分析。A公司对于UI界面无所谓，只要事情办好就成，B、C公司不喜欢千人千面，要个性化，要求定制自己的UI界面。
根据需求，该互联网公司做出了下面的系统（伪代码）

该系统为什么那么做？三家公司财务统计功能都是确定的、一样的，而展示功能有默认的，也有定制的，因此使用超类编写相关功能，使用继承来达到代码复用的目的，而定制化的展示则进行重写覆盖，直截了当。

================================== 情境演进=====================================

该互联网公司的发展很快，业务员太给力了，陆续招揽了很多的公司来采用他们的财务系统，随着业务的扩大，需求也变得越来越多样化，有的公司得财务统计分析要求不仅限于（收入、支出、成本）的简单统计，还需要进行毛利、净利或者是单纯利润的统计等等的需求变化。为此我们不得不进行系统的升级改造。

本来成本、收入、支出都独立成方法会更符合习惯，同时因需求的变更导致的冲突也更明显，利于行文，但为了偷懒就每个都单独写出来了。假设现为独立方法时，那么编写公司D的需求时，我们可以用财务统计公司D类继承财务统计分析父类，然后检查哪些需求是与父类不一致的，毛利、净利为父类没有的，那么新增相应的方法。如果收入的统计方式也不一样，那么不能在父类进行修改，会导致引用了该方法的子类而需求不一致的公司财务统计出现问题，所以得重写…一句话：出现需求差异，不能引用父类方法的，便进行重写。

那么做虽然功能可以实现，但维护会很麻烦，同时会出现重复代码。每新增一家公司都需要进行与父类进行比较，从而决定是否重写方法。同时父类的方法如果进行了更改，还需要去查验每个子类是否有影响，从而决定是否重写覆盖，（如果子类本应没有的行为，但是父类有，而且有可能会轮询所有子类输出该行为的话，那么子类还需要重写一个空方法！）如果子类很多的话，那么脑浆将要炸裂了 。对于代码复用，例如I、J、K、L、M、N对于利润的统计方法实现是一致的，那么这部分代码这样实现是无法复用的。

既然继承无法解决问题，那么是否可以将会变化的行为抽象成接口，确定不变的行为留在父类中，然后如果子类需要用到特定行为便实现特定接口（例如CompanyE子类便可以实现下图的Profit接口）。虽然使用接口解决了父类子类之间的行为差异问题，但代码无法复用的问题更为突出了。

==================================== 策略模式====================================

将行为固定不变的（收入、支出、成本）的实现保留在父类中，从而可以使子类可以轻易共享这部分代码，将经常改变的行为抽出来放到接口中，而实现不再放到子类中去，同时针对该行为不同种类单独的创建实现类，父类持有行为接口成员变量，这样便可以在运行期间实现行为的动态绑定。
下面便是简单实现：

父类变化如下图

子类变化--以公司E为例

接口不再放到子类中进行实现，而是单独进行实现，如下图

策略模式定义：定义算法簇（行为、方法），分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。

结语：水平有限，如有谬误，望指出以免误人。原创不易，转载望声明！