模式2.研磨设计模式之策略模式-1
首先感谢众多朋友的支持、评论和鼓励，只有多多努力，写点好的博文来回报大家的好意！
?
接下来想写写另外一个虽然较简单，但是使用很频繁的模式——策略模式
?
策略模式(Strategy)1? 场景问题1.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
?
?
- 第二个问题：经常会有这样的需要，在不同的时候，要使用不同的计算方式。