模式2.研磨设计模式之策略模式-1

首先感谢众多朋友的支持、评论和鼓励，只有多多努力，写点好的博文来回报大家的好意！

?

接下来想写写另外一个虽然较简单，但是使用很频繁的模式——策略模式

?

策略模式(Strategy)

1? 场景问题

1.1? 报价管理

??????? 向客户报价，对于销售部门的人来讲，这是一个非常重大、非常复杂的问题，对不同的客户要报不同的价格，比如：

• 对普通客户或者是新客户报的是全价
• 对老客户报的价格，根据客户年限，给予一定的折扣
• 对大客户报的价格，根据大客户的累计消费金额，给予一定的折扣
• 还要考虑客户购买的数量和金额，比如：虽然是新用户，但是一次购买的数量非常大，或者是总金额非常高，也会有一定的折扣
• 还有，报价人员的职务高低，也决定了他是否有权限对价格进行一定的浮动折扣
  

  ??????? 甚至在不同的阶段，对客户的报价也不同，一般情况是刚开始比较高，越接近成交阶段，报价越趋于合理。
  ??????? 总之，向客户报价是非常复杂的，因此在一些CRM（客户关系管理）的系统中，会有一个单独的报价管理模块，来处理复杂的报价功能。
  ??????? 为了演示的简洁性，假定现在需要实现一个简化的报价管理，实现如下的功能：
  ?????????? （1）对普通客户或者是新客户报全价
  ?????????? （2）对老客户报的价格，统一折扣5%
  ?????????? （3）对大客户报的价格，统一折扣10%
  ??????? 该怎么实现呢？

  
  1.2? 不用模式的解决方案

  ??????? 要实现对不同的人员报不同的价格的功能，无外乎就是判断起来麻烦点，也不多难，很快就有朋友能写出如下的实现代码，示例代码如下：

  }

  ?

  ??????? 这样看起来，比刚开始稍稍好点，计算报价的方法会稍稍简单一点，这样维护起来也稍好一些，某个算法发生了变化，直接修改相应的私有方法就可以了。扩展起来也容易一点，比如要增加一个“战略合作客户”的类型，报价为直接8折，就只需要在价格类里面新增加一个私有的方法来计算新的价格，然后在计算报价的方法里面新添一个else-if即可。看起来似乎很不错了。
  ????????真的很不错了吗？
  ??????? 再想想，问题还是存在，只不过从计算报价的方法挪动到价格类里面了，假如有100个或者更多这样的计算方式，这会让这个价格类非常庞大，难以维护。而且，维护和扩展都需要去修改已有的代码，这是很不好的，违反了开-闭原则。

  ?

  • 第二个问题：经常会有这样的需要，在不同的时候，要使用不同的计算方式。

    ??????? 比如：在公司周年庆的时候，所有的客户额外增加3%的折扣；在换季促销的时候，普通客户是额外增加折扣2%，老客户是额外增加折扣3%，大客户是额外增加折扣5%。这意味着计算报价的方式会经常被修改，或者被切换。
    ??????? 通常情况下应该是被切换，因为过了促销时间，又还回到正常的价格体系上来了。而现在的价格类中计算报价的方法，是固定调用各种计算方式，这使得切换调用不同的计算方式很麻烦，每次都需要修改if-else里面的调用代码。
    ??????? 看到这里，可能有朋友会想，那么到底应该如何实现，才能够让价格类中的计算报价的算法，能很容易的实现可维护、可扩展，又能动态的切换变化呢？

    ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

    ?

    ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?未完待续......

    注：本文转自???http://chjavach.iteye.com

    ?

    ?