Strategy中文名叫做策略，计谋，一听就知道是为实现某一需求而所使用的方法，相对于编程中的对象也就是对象所表现出来的行为。 Strategy模式主要用来将算法实现从类中分离出来，并封装在一个单独的类中。更简单的说，对象与其行为（behaviour）这本来紧密联系的两部分被解耦，分别放在了两个不同的类中。这使得对同一个 行为，可以方便的在任何时候切换不同的实现算法。而通过对策略的封装，为其提供统一的接口，也可以很容易的引入新的策略。
想起这种设计模式主要是因为最近在使用as3实现panel的几种常见布局，由于布局的算法和容器本身是分离的，使用了策略的设计模式。
为了方便我用GNU的java实现的Layout给大家介绍一下，具体代码可以使用”google代码搜索”来进行搜索相关的类。
AWT的LayoutManager，是 Strategy模式的一个例子。对于GUI而言，每个组件（Component）在容器中（Container）的排放是需要遵循一定的算法的。通常的方法是使用绝对坐标，就像VB，Delphi之类的工具所作的那样，记录每个组件在容器中的位置。这当然会带来一些问题，比如在窗体缩放的时候，就需要手工编码改变组件的大小和位置，以使得原来的比例得以保存。而在AWT中，引入了布局管理器（LayoutManager）的概念，使得布局的方法大大丰富，编码过程也变得简单。
一个容器，比如Applet，Panel等，仅仅记录其包含的组件，而布局管理器中封装了对容器中组件进行布局的算法，具体地说，就是指明容器中组件的位置和尺寸的大小。通过布局管理器，你只需要确定想放置的组件间的相对位置即可，这一方面简化编码，另一方面也有助于实现软件的平台无关性。
每一个容器均有一个布局管理器，当容器需要布置它的组件时，它调用布局管理器的方法布置容器内的组件。LayoutManager2继承于LayoutManager，提供更为细致的布局功能，它可以让布局管理器为组件加上约束条件已确定组件如何被布置。例如，为了确定组件被摆放在边框内的位置，BorderLayout在它的组件上加上方向指示。
特别的，通过实现LayoutManager或者LayoutManager2接口，可以很容易实现自定义的布局策略。
回到模式的话题上来，如果有几个很相似的类，其区别仅仅是在个别行为上的动作不同，这时候就可以考虑使用Strategy模式。这样，通过策略组合，将原来的多个类精简为一个带有多个策略的类。这很符合OO设计的原则：找到变化的部分，并将其封装起来！Strategy模式同样的为子类继承提供了一个好的替代方案，当使用继承机制的时候，行为的改变是静态的，你指能够改变一次–而策略是动态的，可以在任何时候，切换任何次数。更为重要的是，策略对象可以在不同的环境中被不同的对象所共享。以布局管理器为例，虽然每一个容器只有一个布局管理器，但是一个布局管理器可以为多个容器工作。
Strategy模式也有一些缺点，比如，应用程序必须知道所有的策略对象，并从中选者其一。而且在策略对象被使用的时候，它和Context对象之间通常是紧耦合的，Context对象必须为策略对象提供与具体算法相关的数据或者其它的东西，而这些数据的传递可能并不能够风装载抽象地策略类中，因为并不是所有的算法都会需要这些数据的。另外，因为策略对象通常由应用程序所创建，Context对象并不能够控制Strategy的生命期，而在概念上，这个策略应该从属于Context对象，其生命期不应该超出 Context的范围对象。
通常的，Strategy很容易和Bridge模式相混淆。确实，他们有着很相近的结构，但是，他们却是为解决不同的问题而设计的。Strategy模式注重于算法的封装，而Bridge模式注重于分离抽象和实现，为一个抽象体系提供不同的实现。