概念
Strategy Pattern:又叫 政策模式,定义一系列算法类,将每一个算法封装起来,并让它们可以相互替换,策略模式让算法独立于使用它的客户而变化。
使用策略模式时,我们可以定义一些策略类,每一个策略类中封装一种具体的算法。在这里,每一个封装算法的类我们都可以称之为一种策略,根据传入不同的策略类,使环境类执行不同策略类中的算法
使用
这里举例我们的表单验证,平时验证的时候,我会使用条件语句,如下:
1 | <form action="http://xxx.com/register" id="registerForm" method="post"> |
1 | let registerForm = document.querySelector('#registerForm') |
这样会有很多缺点:
- if-else 语句会很多,这些语句需要覆盖所有的校验规则
- 违反 “开闭原则”,如果需要增加一种新的校验规则或者更改校验规则,需要在函数内部进行修改
- 复用性很差,其他表格也需要类似的校验时,可能需要各种复制粘贴
使用策略模式后:
1 | /* Validator类 */ |
优点
符合 ”开闭原则“:可以灵活地增加新的算法或行为
提供了管理相关的算法族的办法:策略类的等级结构定义了一个算法或行为族,恰当使用继承可以把公共的代码移到抽象策略类中,从而避免重复的代码
提供了一种可以替换继承关系的办法:如果不使用策略模式,那么使用算法的环境类就可能会有一些子类,每一个子类提供一种不同的算法。但是,这样一来算法的使用就和算法本身混在一起,不符合“单一职责原则”,决定使用哪一种算法的逻辑和该算法本身混合在一起,从而不可能再独立演化;而且使用继承无法实现算法或行为在程序运行时的动态切换
可以避免多重条件选择语句:多重条件选择语句不易维护,它把采取哪一种算法或行为的逻辑与算法或行为本身的实现逻辑混合在一起,将它们全部硬编码(Hard Coding)在一个庞大的多重条件选择语句中,比直接继承环境类的办法还要原始和落后
提供了一种算法的复用机制:由于将算法单独提取出来封装在策略类中,因此不同的环境类可以方便地复用这些策略类
缺点
- 客户端必须知道所有的策略类,并自行决定使用哪一个策略类。换句话说,策略模式只适用于客户端知道所有的算法或行为的情况
- 将造成系统产生很多具体策略类,任何细小的变化都将导致系统要增加一个新的具体策略类
- 无法同时在客户端使用多个策略类,也就是说,在使用策略模式时,客户端每次只能使用一个策略类,不支持使用一个策略类完成部分功能后再使用另一个策略类来完成剩余功能的情况