《HeadFirst设计模式》读书笔记一:策略模式

《HeadFirst设计模式》读书笔记一:策略模式

1 从一堆鸭子说起

众所周知《机器学习》(周志华版)被称为西瓜书,我觉得《Head First 设计模式》也可以被称为鸭子书~ 假设有这么一个模拟鸭子游戏SimUDuck,游戏中会出现各种鸭子,它们一边游泳一边呱呱叫。于是有这么一个鸭子超类,并且让各种鸭子继承这个超类;

image.png
这看起来似乎还不错,所有的鸭子都会继承Duck超类,并且只需要重写display方法以打印自己的特征就可以。但需求是在变化的

2 让鸭子飞起来!

好吧,看起来不难,我们只需要给Duck类加一个fly()方法并实现就可以了;确实这样一来所有继承Duck类的鸭子都会飞了,但是我们忽略了一个事实——不同子类之间的差异性,橡皮鸭子原本不会飞现在飞起来了!

对代码的局部修改 影响的不一定只停留在局部;当涉及“维护”时,为了“复用”目的而使用继承,结局并不完美
我的理解:对超类的修改要谨慎,避免造成不必要的麻烦!如无必要,勿增实体

2.1 解决办法:子类重写

我们可以重写不会飞的橡皮鸭子的fly方法,将其改为什么也不做就可以了。
这确实解决了橡皮鸭可以飞的问题,但是以后每次设计新的子类的时候,我们都需要检查fly、quack、swim等方法,这就失去了复用的意义。

通过继承提供Duck的行为,可能会带来的缺点

代码在多个子类中重复(需要改写行为以适应不同子类)
运行时的行为不容易改变(无法灵活切换)
很难知道所有鸭子的全部行为
改变会牵一发而动全身,导致其他鸭子不想要的改变

2.2 解决办法:通过接口

接口是对行为的抽象,可以把fly()、quack()从超类中提取出来,放进Flyable、Quackable接口,然后只有会飞、会叫的鸭子才回去实现这个接口。
但这一来重复的代码将变得更多,对于每一种会飞、会叫的鸭子都需要去实现对应的接口,此外还有不同飞行方法、不同叫声的叫法,这使得代码的可复用性降得很低。

2.3 重新审视问题

首先我们知道在这个案例中,fly是新加入的需求~
并且使用继承并不能很好地解决问题,因为鸭子的行为在子类里不断地改变,并且让所有的子类都有这些行为是不恰当的。Flyable与Quackable接口一开始似乎还挺不错,解决了问题(只有会飞的鸭子才继承Flyable),但是Java接口不具有实现代码,所以继承接口无法达到代码的复用。
这意味着: 无论何时你需要修改某个行为,你必须得往下追踪并在每一个定义此行为的类中修改它,一不小心,可能会造成新的错误!
幸运的是,有一个设计原则,恰好适用于此状况。

设计原则: 找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。

下面是这个原则的另一种思考方式:“把会变化的部分取出并封装起来,以便以后可以轻易地改动或扩充此部分,而不影响不需要变化的其他部分”。-->系统变得更有弹性

这样的概念很简单,几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让“系统中的某部分改变不会影响其他部分”。
好,该是把鸭子的行为从Duck类中取出的时候了!

3 抽离易于变化的部分

一种方法是建立2组完全远离Duck类的Class,每一组类将实现fly、或者是quack,而类中有对于fly的不同实现;而且可以使得鸭子的行为可以动态地改变(setter)

设计原则:针对接口编程,而不是针对实现编程。

我们利用接口代表每个行为,行为的每个实现都将实现其中的一个接口。这样的做法迥异于以往,以前的做法是:行为来自Duck超类的具体实现,或是继承某个接口并由子类自行实现而来。

这两种做法都是依赖于“实现”,我们被实现绑得死死的,没办法更改行为(除非写更多代码)。在我们的新设计中,鸭子的子类将使用接口(FlyBehavior与QuackBehavior)所表示的行为,所以实际的“实现”不会被绑死在鸭子的子类中(鸭子不会负责实现Flyable、Quackable接口)。(换句话说,特定的具体行为编写在实现了FlyBehavior与QuakcBehavior的类中,从而实现了解耦)。

这样的设计,可以让飞行和呱呱叫的动作被其他的对象复用,因为这些行为已经与鸭子类无关了;并且我们也可以新增一些行为(不同的实现),不会影响到已有的行为类和“使用”其他已有行为的鸭子类。

这么一来,有了继承的“复用”好处,却没有继承所带来的包袱。

image.png

4 复盘

你也许可能听过Has-A is Better than is-A的说法,也许你可能像我一样此前并没有很直接地感受到或者思考过Why Has-A is Better than is-A?
但通过鸭子的例子我想你应该有一些感受了,is-A也就是继承的关系(不同的鸭子继承超类Duck),而has-A更偏向于组合的关系(鸭子类有FlyBehavior类和QuackBehavior类,鸭子是容器/对象,而后两者是容器/对象的组件类)

 设计原则:多用组合,少用继承

如你所见,使用组合建立系统具有很大的弹性,不仅可将算法族(对于同一个行为的不同实现方法)封装成类,更可以“在运行时动态地改变行为”(setter方法),只要组合的行为对象符合正确的接口标准即可。
组合用在许多设计模式中,它也有许多优点和缺点,在之后的学习中我们还会继续讨论;

5 策略模式

策略模式是一种行为型设计模式, 它可以在运行时选择算法;与直接实现某个算法不同,代码在运行时可以选择在算法族中选取一个执行。
(In computer programming, the strategy pattern (also known as the policy pattern) is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.wikipedia)

或者说

策略模式将某一个行为(接口)通过不同的方法/算法实现[上文所提的算法族],方便需要实现该接口对应行为[Has-A]的程序/客户可以在"运行时"灵活切换该行为实现的方法/策略,使得策略的变化独立于使用它的客户/程序;