天天看点

策略模式总结,适用场景,优缺点,代码示例

1、简介

1.1 继承带来的扩展和复用问题

1.2 进一步改进,利用接口

1.3 进一步改进,策略模式

2、适用场景

3、优点

4、缺点

5、代码示例

6、源码分析

6.1 spring中应用

7、策略模式总结、类图

相关参考博文:

博客园:

spring2sun:设计模式系列

定义了一系列的算法,把他们封装起来,他们相互之间可以替换,某个算法的调整或者新增不会影响其他的算法,是在执行期间来选择具体的算法,使用什么算法被推迟到运行时,使得系统更加灵活,复用性更高,该模式可以减少if else的数量,属于行为型。

context封装角色

也叫做上下文角色,起承上启下封装作用,屏蔽高层模块对策略、算法的直接访问,封装可能存在的变化。

strategy抽象策略角色

策略、算法家族的抽象,通常为接口,定义每个策略或算法必须具有的方法和属性。

concreatestrategy

实现抽象策略中的操作,该类有具体的算法。

继承作为面向对象的三大要素(封装、继承、多态)之一为什么会带来问题,问题如何解决然后形成一种设计模式,head frist设计模式书中以鸭子作为例子讲解什么情况下继承的方式会带来问题。首先有各种各样的鸭子,那么自然想到各种鸭子继承自一个父类:父类为duck,现有绿头鸭greenheadduck和红头鸭redheadduck:

父类中所有鸭子都会呱呱叫(quack)和游泳(swin),外观却不一样所以display为抽象方法,让继承它的子类重写。现在需要新增一种鸭子,但这个鸭子是一个玩具橡皮鸭,我们按照继承的方式则橡皮鸭实现代码如下:

因为橡皮鸭是不会像其他鸭子那样叫的,所以上面代码我们需要重写qucak覆盖橡皮鸭叫的方式可。现在有一个需求,需要让鸭子飞起来,按照继承的方式我们给父类duck添加 fly方法即可让所有鸭子飞起来。但是问题出现了,橡皮鸭是不会飞的,于是我们可以像覆盖qucak方法一样在rubberduck中覆盖fly方法。

到这里我们已经发现了继承带来的问题:

代码在多个子类中重复。

很难知道所有子类的行为。

运行的子类行为不容易改变。

改变会牵一发动全身,引起其他子类不想要的改变。

每当有新的子类出现,就要检查是不是需要覆盖父类方法。比如再加一种木头玩具的鸭子(decoyduck),那么木头鸭子不会叫也不会飞,我们是不是需要覆盖叫和飞的方法。

由于quack和fly有可能变化,所以我们将quack 和fly抽象成接口,能够叫和飞行的鸭子才按需求继承接口自己实现方法。

策略模式总结,适用场景,优缺点,代码示例

利用接口可以解决一部分问题(不在需要重写不需要的方法),但是却会造成代码无法复用,因为接口不具有实现,我们要在每种子类中写fly和quack。比如要在红头绿头中写"呱呱叫",要在橡皮鸭中写"吱吱叫"。

经过上面的分析可以引出设计模式的两个原则:

把会变化的部分封装起来,让其他部分不会受到影响。

针对接口编程,而不是针对实现。

通过第一个设计原则我们可以取出易于变化的部分:鸭子的飞行行为(fly)和呱呱叫的行为(quack)。通过第二个设计原则我们知道需要利用接口代表每个行为,比如flybehavior与quackbehavior,而行为的每个实现都将实现其中的一个接口。这样鸭子类就不会负责实现flybehavior与quackbehavior,而是由行为类来专门实现,不会绑死在鸭子的子类中。

策略模式总结,适用场景,优缺点,代码示例

而"针对接口编程"的意思是"针对超类型编程"。可以明确地说明变量的声明类型应该是超类,这意味着我们在duck父类中声明的行为变量为 flybehavior,quackbehavior,“针对接口编程"的关键就在于面向对象三要素之一的"多态”,由于多态我们才能在调用超类的方法时执行的是实现类或子类的方法。所以我们改造之前写的duck类,删除fly()和quack(),加入flybehavior和quackbehavior变量,并用另外两个方法performfly()和performquack()来执行两个行为。

编写相关类并测试:

如上测试我们在鸭子子类中通过构造方法实例化行为类,但建立了一堆动态的功能没有用到,是否可以动态的设定行为而不是在构造函数里面实例化。所以我们还可以加入两个设置行为的方法 setflybehavior和setquackbehavior,再次测试动态设定行为。

策略模式总结,适用场景,优缺点,代码示例

系统有很多类,但是他们的区别只是行为不同

一个系统需要动态的在几个算法中选择一种

多个类只有在算法或行为上稍有不同的场景

算法需要自由切换的场景

需要屏蔽算法规则的场景

注意事项:

具体策略数量超过4个,则需要考虑使用混合模式。

1、可以减少ifelse语句

2、提高算法的保密性和安全性

3、符合开闭原则

1、客户端需要知道所有策略类,自己决定使用哪个策略类

2、类的数量增加

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bhcvnhwc-1608389668751)(https://img.hacpai.com/file/2019/07/image-447d0de5.png?imageview2/2/w/768/format/jpg/interlace/1/q/100)]

订单策略接口

支付宝下单策略

微信下单策略

空策略类

订单类型枚举类

下单工厂类

测试类

输出结果为:

resource

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w5uzzxjg-1608389668755)(https://img.hacpai.com/file/2019/07/image-cd73df82.png?imageview2/2/w/768/format/jpg/interlace/1/q/100)]

如图,有不同的策略类,

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lnpd49zr-1608389668756)(https://img.hacpai.com/file/2019/07/image-2ec69237.png?imageview2/2/w/768/format/jpg/interlace/1/q/100)]

instantiationstrategy从名字上就可以看出是策略模式,

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kfyog01n-1608389668758)(https://img.hacpai.com/file/2019/07/image-66f96b08.png?imageview2/2/w/768/format/jpg/interlace/1/q/100)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-00o1umwv-1608389668759)(https://img.hacpai.com/file/2019/07/image-57873357.png?imageview2/2/w/768/format/jpg/interlace/1/q/100)]

也可以通过set方法来进行配置。

策略模式:定义了算法簇,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户

策略模式总结,适用场景,优缺点,代码示例

继续阅读