在编写面向对象的代码的时，有些时候你需要一个能够自己根据不同的条件来引入不同的操作对象实例。例如，一个菜单功能能够根据用户的“皮肤”首选项来决定是否采用水平的还是垂直的排列形式，或者一个计费系统可以自行根据用户的收货地址来决定税率。
　　
　　一般来讲，一个控制菜单的对象实例包括了add(),delete(),和replace()等菜单元素；并通过set()进行配置，用render()来管理显示模式。无论你想生成什么样子的菜单，你都可以用同一个对象类来处理。不同菜单的对象实例只是一些方式函数的运算规则不同罢了，至少在刚才的例子里面render()函数是不同的。
　　
　　但是如果你需要增加菜单的显示模式种类，或者你需要根据用户的国家、省份等信息来判断菜单排列的顺序的时候，该怎么做呢？而且如果有许多的方式函数都是经常变化的，那么简单的类封装将变得复杂、难易理解和升级的。
　　
　　问题
　　
　　怎么轻松地改变对象实例的执行过程，因而在代码执行的时候动态地改变执行过程？一旦实现了这个功能，如果去编写这样的类定义从而让维护和升级变得非常简单呢？
　　
　　解决办法
　　
　　当一个类封装了多个操作的时候，对象实例可以动态地选择这些操作来进行，可以用策略模式来把对象本身和运算规则区分开来。或者，更简单的处理是类里面定义的方式函数用case语句来进行控制。当然更简单的方法是使用策略模式。
　　
　　策略模式功能非常强大，因为这个设计模式本身的核心思想就是面向对象编程的多形性的思想。
　　
　　就在编程领域之外，有许多例子是关于策略模式的。如果我需要在清晨从家里去上班，我可以有几个策略可以考虑：我可以开车，乘坐公交车，走路，汽车或者甚至是搭乘直升飞机。每个策略都可以得到相同的结果，但是它们使用了不同的资源。选择策略的依据是费用，时间，使用工具还有每种方式的方便程度。一个很好的策略也许在第二天就不能再被使用的，所以策略的选择是相对的。
　　
　　你已经在前面的工厂模式章节看到了和策略模式相似的例子:因为不同特性的费用计算方式不同，所以Monopoly游戏的框架使用了许多相似的特性类，但是因为费用的计算不是从类本身获得，所以这个费用计算相对来说是一个TemplateMethod设计模式。