一. 概述
考虑如下情景,超市搞打折活动,对于消费额度不同提供不同的折扣,比如:满200打9折,满400打8折之类的;或者旅行出游的情景,可以考虑骑自行车,坐汽车、火车、飞机等等。
如何实现上面描述的情景,当然最直接想到的是使用if…else进行判断,执行不同的操作,但是如果在你实现完后有添加了其他的活动或者出行方式呢,这个时候你需要在客户端直接修改代码。
当然,也可能想到之前提到过的工厂模式,但是工厂模式主要是解决对象的创建问题,而打折方式,出行方式这种行为都属于一系列的算法,如何让算法和对象分开来,使得算法可以独立于调用它的客户端变化就是策略模式解决的问题。
策略模式(Strategy)
定义了算法家族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化,不会影响到使用算法的客户。
策略模式属于对象的行为模式。
二. UML类图解析
策略模式的UML图如下所示:
- IStrategy:策略接口类,定义所有支持的算法的公共接口。(如果算法存在公共的实现逻辑,可以采用抽象类,以继承的方式实现算法,可以把公共代码移到父类,避免代码重复)
- StrategyA、StrategyB:具体策略类,封装了具体的算法或行为,实现IStategy。
- Context:Context上下文,其中定义一个方法来进行配置,维护一个对IStrategy的引用。
三. 代码实现
就用上面提到的旅游出行来作为具体的场景用代码进行实现。
策略接口——ITravelStrategy
1 | package io.github.brightloong.design.strategy; |
策略实现——AirPlaneStrategy
1 | package io.github.brightloong.design.strategy; |
策略实现——TrainStrategy
1 | package io.github.brightloong.design.strategy; |
上下文环境类——TravelContext
1 | package io.github.brightloong.design.strategy; |
客户端调用——Tourist
1 | package io.github.brightloong.design.strategy; |
输出
1 | 坐飞机出游。 |
四. 扩展
在上面的客户端调用中,发现需要客户端了解所有的策略实现,并且需要客户端自己判断使用哪一种策略,如果想将这个判断从客户端移走,这个时候可以将策略模式和简单工厂模式进行结合,修改后的TravelContext如下:
1 | package io.github.brightloong.design.strategy; |
五.使用场景
- 如果在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
- 一个系统需要动态地在几种算法中选择一种,需要在不同情况下使用不同的策略(算法),或者策略还可能在未来用其它方式来实现。
- 对客户隐藏具体策略(算法)的实现细节,彼此完全独立。
- 出现同一抽象类有多个子类,并且使用判断逻辑if-else之类的来判断选择具体子类。
六. 总结
优点
- 上面提到了,并不一定要使用策略接口,也可以使用抽象类,恰当使用继承可以把公共的代码移到父类里面,从而避免代码重复。
- 具有良好的扩展性,新增算法只用添加策略实现。
- 不同算法之间可以自由切换。
- 使用策略模式可以避免使用多重条件(if-else)语句。
缺点
- 客户端必须知道所有的策略类,并自行决定使用哪一个策略类。策略模式将责任交给了客户端去承担。
- 随着策略的不断增加,将产生越来越多的策略类,导致了类膨胀。