设计模式 ☞ 行为型之策略模式

1.1 简介

1.1.1 概述

  策略(Strategy)模式的定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。   在软件开发中也常常遇到类似的情况，当实现某一个功能存在多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能，如数据排序策略有冒泡排序、选择排序、插入排序、二叉树排序等。

在这里插入图片描述

1.1.2 优缺点

优点：  ① 多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句，如 if…else 语句、switch…case 语句。  ② 策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。  ③ 策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。  ④ 策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。  ⑤ 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。

缺点：  ① 客户端必须理解所有策略算法的区别，以便适时选择恰当的算法类。  ② 策略模式造成很多的策略类，增加维护难度。

1.2 案例

  策略模式建议找出负责用许多不同方式完成特定任务的类，然后将其中的算法抽取到一组被称为策略的独立类中。名为上下文的原始类必须包含一个成员变量来存储对于每种策略的引用。上下文并不执行任务，而是将工作委派给已连接的策略对象。   上下文不负责选择符合任务需要的算法——客户端会将所需策略传递给上下文。 实际上，上下文并不十分了解策略，它会通过同样的通用接口与所有策略进行交互，而该接口只需暴露一个方法来触发所选策略中封装的算法即可。因此，上下文可独立于具体策略。这样你就可在不修改上下文代码或其他策略的情况下添加新算法或修改已有算法了。   在导航中，每个路线规划算法都可被抽取到只有一个生成路线方法的独立类中。 该方法接收起点和终点作为参数，并返回路线中途点的集合。即使传递给每个路径规划类的参数一模一样，其所创建的路线也可能完全不同。主要导游类的主要工作是在地图上渲染一系列中途点，不会在意如何选择算法。该类中还有一个用于切换当前路径规划策略的方法，因此客户端可用其他策略替换当前选择的路径规划行为。

在这里插入图片描述