模版方法模式与策略模式如何让软件开发符合“开闭原则”

背景描述

• 在实现一个需求时，通常开发人员都不会准确预测到功能以后会如何改变，如果设计的代码不符合“开闭原则”，那么将来需求稍微变动，往往程序就要进行较大改动，或者代码十分臃肿，不利于维护。
• 我以一个具体的场景来说明，曾经做过这样一个需求，一个网上商店需要根据用户所选商品进行结算，这里结算的方式当时已知有“支付宝”跟“银联”，如何来设计支付的业务逻辑？
• 很明显，该需求后期可能会改动，比如现在有微信支付，Paypal等，总之，随着时间的迁移，总会有许多新的支付方式产生。有的开发可能会想到使用策略模式，根据用户选择的不同的支付方式来设置。下面来看一看：

策略模式

• 下面是策略模式的UML图：
  
• 大致思想就是根据用户选择的支付方式设置stragety，比如用户使用支付宝支付，那么在context中的支付方式就是支付宝支付。
• 其中支付方式接口如下：
  
  

  PayMethod表示支付方式的接口，各种具体的支付方式实现该接口以处理对应的支付业务。

• 支付宝的支付类实现如下，银联支付实现类与上面类似，这里不再列举。 
  

• 处理支付逻辑的类的实现如下：
  
  

  从上面可以看出，的确使用了策略模式来实现了支付业务，但是稍微一想，以后要是新增微信支付的话，上面是不是又得加个if判断语句，这样就对原有逻辑进行了改动，没有很好得满足“开闭原则”，这时候就要想想其它方法了，

  这就是模版方法模式跟策略模式的混合类型。

模版方法模式跟策略模式混合类型

• 模板方法模式的大致思想是：将业务处理的共同逻辑抽取出来，个性部分下沉到各个具体的子类去实现，也是一种常见的设计模式，它的类图如下：
  
• 其中支付方式接口如下：（注意我们将code放到参数中去了，这是因为模版方法的需要）
  

• 其中的抽象模板类如下：（新增了两个抽象方法）
  

• 支付宝的支付类实现如下（实现了抽象模板类中的两个方法）：
  

• 处理支付逻辑的类的实现如下：

  

  这样的话以后不管增加什么类型的支付方式都不用改上面的支付逻辑啦，只需要新增相应的实现类即可，实现其中的isContent()跟pay()方法即可。

  这样是不是就满足了开闭原则啦，是的，很好的满足了开闭原则，实际上我个人经历告诉我：大多数需求都可以按照这种抽象方式来做，

  这样的代码不会出现臃肿和难以扩展的问题，大家有什么问题可以提出来和我一起讨论。