本文共 1130 字,大约阅读时间需要 3 分钟。
策略模式定义了算法族,分别封装起来,让它们之间可以互相替换。此模式让算法的变化独立于使用算法的客户。核心思想是将变化的部分抽离为独立维度。
鸭子种类:绿头鸭、红头鸭、橡皮鸭
行为:quack()---呱呱叫,swim()---游泳,display()---展示外观。
附:橡皮鸭不会呱呱叫,而是吱吱叫。
可能我们会这么设计:
鸭子种类:绿头鸭,红头鸭,橡皮鸭,木头鸭
行为:quack(),swim(),display(),fly()---飞行
附:橡皮鸭会吱吱叫不会飞,木头鸭不会叫不会飞。其他的鸭子会呱呱叫会飞。
这时候我们有以下几种思路
1.将fly()方法放入抽象父类Duck中,这样所有的鸭子子类都需要实现fly()方法,即使它不会飞,虽然我们可以为不会飞的鸭子提供空的fly()方法实现。但是这种封装逻辑还是会很奇怪。
1.1将fly()实现放在Duck中的时候,对于可维护、可扩展性是不好的。(比如说我后面又需要区分会飞鸭子,进行不同 的飞行 处理,那么只能够在子类中覆盖fly()方法,这显然是不符合OCP原则的,长期如此系统会变得难以维护。其中RubberDuck提 供fly()的空实现,DecoyDuck提供quack()和fly()的空实现)
1.2将fly()的抽象放到Duck中,实现放到子类中的时候,就会有大量重复的代码(红框),因为很多鸭子的飞行行为是完全一 致的。(其中RubberDuck提供fly()的空实现,DecoyDuck提供quack()和fly()的空实现)
2.将鸭子的不同行为抽象为接口
这样做也是有问题的。
其一是不易于扩展,以后我要是说swim()行为也有新品种的鸭子没法游泳。咋办,你还得动现在的类,不符合OCP,随着鸭子种类的增加,这种问题随时会出现。
其二是大量重复的代码,,接口相比于抽象类就是没有办法提供公有的实现。导致MallardDuck和RedheadDuck中有重复的代码,意味着你需要维护两份。
3.可能有些朋友第一反应是既然接口不行,我用抽象类啊,将Flyable和Quackable写成抽象类,将公有的实现放在里面不就结了?
然而Java不支持多继承。。就算是支持,如果以后要区分对待也是不好处理的。
4.将变化的和不变的分离,将不变的抽离出来,并用组合的方式建立与不变部分的关联,就是我们要讲的策略模式
这种做法看起来似乎很复杂。但事实上是极好的。后面只要有什么行为需要独立于鸭子使用,都可以扩展出一个新的族,现有的族也很好扩展。并且通过组合与Duck关联,耦合性低。