IDEA或eclipse
在软件系统中，有许多算法可以实现某一功能，如查找、排序等，一种常用的方法是硬编码(Hard Coding)在一个类中，如需要提供多种查找算法，可以将这些算法写到一个类中，在该类中提供多个方法，每一个方法对应一个具体的查找算法；当然也可以将这些查找算法封装在一个统一的方法中，通过if…else…等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码，如果需要增加一种新的查找算法，需要修改封装算法类的源代码；更换查找算法，也需要修改客户端调用代码。在这个算法类中封装了大量查找算法，该类代码将较复杂，维护较为困难。
我们来实现一下上面有问题代码之前，一定要明确一个问题，我们封装的算法是给客户端使用的，也就是说算法在服务端（也很可能是一个jar包，客户端引用），上面所说的硬编码指的是要在服务端硬编码！
然后client引用这个jar包到自己的classpath下，调用。现在问题来了，如果要新加入一个算法怎么办！那么只能修改AlgorithmUtil这个类，增加一个方法，也就是服务端需要修改源码！完全不符合“开放封闭原则'!我们肯定希望动态的增加类解决这个问题！
也可以将这些算法封装在一个统一的方法中，通过if…else…等条件判断语句来进行选择。这样的目的是方便客户端，但如果逻辑变了，还是要改动server的源码,代码实现如下
ok，为了解决这些问题，我们进入正题，策略模式，先把策略抽象成一个接口。
然后，具体的策略实现类，我们定义了StrategyA和StrategyB
最后写一个Context封装算法
客户端调用
ok，根据UML图来看下，这个时候服务端增加一种算法，只需要增加一个子类就好了，客户端把这个子类传入context中就可以调用，不用修改原来的类，完全符合开放封闭原则！服务端无论是扩展功能，还是打补丁都很方便！
缺点：算法对客户端开放了，增加了客户端的使用难度，并且很可能产生很多算法子类。
不要期望设计模式解决所有问题！具体的设计模式一定要卡场景！
如果你把某一种设计模式无限放大的想！那么你一定会很痛苦！