"策略模式是对算法的包装，是把使用算法的责任和算法本身分割开，委派给不同的对象管理......"(<java与模式>)，其简单示意类图如下：
文中提到，策略模式仅仅是封装算法，至于客户端具体要使用哪个具体策略类，则由客户端去判断。
个人十分不理解这种做法，既然要客户端知道所有的具体策略类，并且去判断使用谁，那何必对具体策略类进行抽象呢？进行抽象后，客户端可能会如下使用各种策略：
IStrategy someStrategy = new ConcreteStrategy1();someStrategy.doSomething(); //运行策略IStrategy otherStrategy = new ConcreteStrategy2();otherStrategy .doSomething(); //运行策略我实在看不到强大的“抽象”工具在这里提供的好处，如果不进行抽象同样可以通过:ConcreteStrategy1 someStrategy = new ConcreteStrategy1();来进行具体策略的使用。难道说这个抽象仅仅是为了规范接口而已？
具体例子：在<java与模式>中，举了使用Strategy模式的一个例子--图书折扣的计算，在这个例子中，客户端要对图书进行判断，属于哪类折扣书籍，然后再实例化具体的策略类进行调用。个人认为，这并不符合设计模式中职责分离的原则，一些不应该有客户来做的事却分配到了客户对象里。我觉得，客户所应该做的仅仅是，他得到一批书籍，现在想知道这批书籍的折扣，具体哪本书怎么折扣应该交给其他对象来计算。所以，我想象中的策略模式应该在Client和IStrategy之间再加入一个策略管理对象，大概示意图如下：
这样就把判断使用哪个具体策略的职责转嫁到了StrategyManager上，当然，Client需要将某些标识传给StrategyManager以判断选择哪个具体策略类。我认为这样可以进一步简化客户端的编码，同时也利于维护和扩展。
以上就是个人对策略模式的一点思考，如有不妥之处，还望各位指教~~
