HeadFirst_01,策略模式
HeadFirst示意图
策略者模式定义了算法族,分别封装起来,让他们之间可以相互替换,此模式让算法的变化独立于使用算法的客户。
书籍内容介绍:
相关源码地址:https://github.com/wenutopia/HeadFirst.git
网上相关内容介绍
策略模式中主要有3个角色
- 抽象策略接口:抽象策略接口,接口中定义了抽象的策略算法
- 具体的策略实现类:具体的策略实现。不同的策略实现类都实现了抽象策略接口,并重写了其抽象策略方法。因为都实现了相同的策略接口,因而算法可以相互替换,并且可以动态的改变具体的算法实现。
- 封装策略的上下文环境:策略的上下文环境。它屏蔽了高层模块对策略算法的直接访问,封装了可能存在的变化,动态的改变算法的具体实现
策略模式和java语言的多态特性有些像。java的多态特性允许我们面向接口编程,不用关心接口的具体实现。接口所指向的实现类,以及通过接口调用的方法的具体行为可以到运行时才绑定。这么做最大的好处是在尽可能实现代码复用的前提下更好地应对具体实现类的变化。比如我想增加一种接口的实现或者修改原有实现类的某个行为,那我几乎不用修改任何客户端代码。策略模式可以说正是这种思想在设计模式上的运用。它可以使我们更好的复用代码,同时使程序结构设计更有弹性,更好的应对变化。
策略模式的优点:
- 策略模式的功能就是通过抽象、封装来定义一系列的算法,使得这些算法可以相互替换,所以为这些算法定义一个公共的接口,以约束这些算法的功能实现。如果这些算法具有公共的功能,可以将接口变为抽象类,将公共功能放到抽象父类里面。
- 策略模式的一系列算法是可以相互替换的、是平等的,写在一起就是if-else组织结构,如果算法实现里又有条件语句,就构成了多重条件语句,可以用策略模式,避免这样的多重条件语句。
- 扩展性更好:在策略模式中扩展策略实现非常的容易,只要新增一个策略实现类,然后在使用策略实现的地方,使用这个新的策略实现就好了。
策略模式的缺点:
- 客户端必须了解所有的策略,清楚它们的不同,如果由客户端来决定使用何种算法,那客户端必须知道所有的策略,清楚各个策略的功能和不同,这样才能做出正确的选择,但是这暴露了策略的具体实现。
- 增加了对象的数量:由于策略模式将每个具体的算法都单独封装为一个策略类,如果可选的策略有很多的话,那对象的数量也会很多。
- 只适合偏平的算法结构:由于策略模式的各个策略实现是平等的关系(可相互替换),实际上就构成了一个扁平的算法结构。即一个策略接口下面有多个平等的策略实现(多个策略实现是兄弟关系),并且运行时只能有一个算法被使用。这就限制了算法的使用层级,且不能被嵌套。
策略模式的本质:分离算法,选择实现。
如果你仔细思考策略模式的结构和功能的话,就会发现:如果没有上下文,策略模式就回到了最基本的接口和实现了,只要是面向接口编程,就能够享受到面向接口编程带来的好处,通过一个统一的策略接口来封装和分离各个具体的策略实现,无需关系具体的策略实现。
策略模式体现了开闭原则:策略模式把一系列的可变算法进行封装,从而定义了良好的程序结构,在出现新的算法的时候,可以很容易的将新的算法实现加入到已有的系统中,而已有的实现不需要修改。
策略模式体现了里氏替换原则:策略模式是一个扁平的结构,各个策略实现都是兄弟关系,实现了同一个接口或者继承了同一个抽象类。这样只要使用策略的客户端保持面向抽象编程,就可以动态的切换不同的策略实现以进行替换。
自我举例
person从家到学校的实现方式
用策略模式实现思路:
- 为这些方式,提供 接口A
- 将具体的方式,如:跑、走…,定义单独的类去实现 接口A
- 再定义使用这些方式的类Person,将接口A作为局部参数传给B,这样就可以实现在不影响其他方式的情况下,动态选择去学校的方式
下周看点:java注解