设计模式（三）--策略模式

策略模式的结构图：

引用:模版方法模式，对照类图可以看到，策略模式与模版方法模式的区别仅仅是多了一个单独的封装类Context，它与模版方法模式的区别在于：在模版方法模式中，调用算法的主体在抽象的父类中，而在策略模式中，调用算法的主体则是封装到了封装类Context中，抽象策略Strategy一般是一个接口，目的只是为了定义规范，里面一般不包含逻辑。其实，这只是通用实现，而在实际编程中，因为各个具体策略实现类之间难免存在一些相同的逻辑，为了避免重复的代码，我们常常使用抽象类来担任Strategy的角色，在里面封装公共的代码，因此，在很多应用的场景中，在策略模式中一般会看到模版方法模式的影子。

红字表示：策略模式、模板方法、简单工厂，在抽象思想上基本一致的，把看似不同的东西，抽象通用接口，封装变化。实则，这就是面向对象的继承与多态。

区别：

• 策略模式，更偏向一种库封装。迪米特法则更好，用户只需要面对一个类接口。其他的都可以在Conetext内部完成。
• 简单工厂，偏向创建对象的过程，用户只需要告诉工厂创建一个对象，并返回。用户频繁的创建某类对象，用户创建对象之后，如何使用对象的特性。所以客户端必须理解，工厂内部每一个类的特性，迪米特法则没有策略模式好，更注重对象创建的过程。
• 模板方法，偏向于继承的概念，工厂与策略侧重点都是接口的抽象。模板方法，侧重相同的部分抽象出来，避免代码重复。在编码中，简单工厂与策略模式都可以达到模板方法的目的。但是思想侧重不同。模板方法，在客户端代码中，耦合度要比其他两个都高，因为客户端面对的都是实体类，当业务变化是，可能需要修改客户端代码。

引用

策略模式的优缺点

       策略模式的主要优点有：

• 策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。
• 易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。
• 避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，在上一篇文章中我们已经提到，使用多重条件判断是非常不容易维护的。

       策略模式的缺点主要有两个：

• 维护各个策略类会给开发带来额外开销，可能大家在这方面都有经验：一般来说，策略类的数量超过5个，就比较令人头疼了。
• 必须对客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严重。例如，有一个排序算法的策略模式，提供了快速排序、冒泡排序、选择排序这三种算法，客户端在使用这些算法之前，是不是先要明白这三种算法的适用情况？再比如，客户端要使用一个容器，有链表实现的，也有数组实现的，客户端是不是也要明白链表和数组有什么区别？就这一点来说是有悖于迪米特法则的。

 

适用场景

        做面向对象设计的，对策略模式一定很熟悉，因为它实质上就是面向对象中的继承和多态，在看完策略模式的通用代码后，我想，即使之前从来没有听说过策略模式，在开发过程中也一定使用过它吧？至少在在以下两种情况下，大家可以考虑使用策略模式，

• 几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
• 有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。

       策略模式是一种简单常用的模式，我们在进行开发的时候，会经常有意无意地使用它，一般来说，策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。