《Head First设计模式》 读书笔记11 状态模式
The State Pattern
问题引入
本章的实例问题是一个糖果机的控制器，有几个状态，不同的动作会有不同的响应。
比如投币再转动曲柄，会发放糖果，糖果没有了会显示售罄等等。
第一版的程序
下面是一个从状态图实现状态机代码（state machine）的简单介绍：
1.首先，找出所有的状态。
2.接下来，创建一个实例变量来持有目前的状态，然后定义每个状态的值。
3.之后，将系统中所有可以发生的动作整合起来。
4.创建类代码，对每一个动作创建一个方法，在方法中利用条件语句来决定不同状态的行为，有可能发生的动作或者状态转换。
这一版的程序特点：
设计周密，每一个方法中都对各个状态进行了判断。
但是需求变更时更改代码会比较困难，首先，要加上新的状态，然后必须在每个方法中加上新的条件判断，有的状态逻辑还可能会被打乱重新整理，也就是说，未来加入的代码很有可能导致bug。
新的设计
要得到一个容易维护的设计，我们要做的事情是：
1.首先，定义一个State接口，在这个接口内，糖果机的每个动作都有一个对应的方法。
2.然后为机器中的每个状态实现状态类，每个状态类都实现State接口。这些类将负责在对应的状态下进行机器的行为。
3.最后，我们要摆脱旧的条件代码，取而代之的方法是，将动作委托到状态类。
即现在我们要把一个状态的所有行为放在一个类中，这么一来我们将行为局部化了，并使得事情更容易改变和理解。
重新改造糖果机，把原来使用整数代表的状态改为状态对象；之后糖果机中的所有动作变得很容易实现了，只需要委托到当前状态的相应动作就可以了。机器的当前状态总是这些类的实例之一。
实现细节：需要把对机器的引用通过构造方法传入每一个状态类中，这样每一个状态类都持有一个对机器的引用，可以调用其setState(State state)方法来进行状态的切换。
状态模式的定义
状态模式允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
这个模式将状态封装成独立的类，并将动作委托到代表当前状态的对象，这就是说行为会随着内部状态而改变。
“看起来好像修改了它的类”是什么意思呢？从客户的视角来看：如果说你使用的对象能够完全改变它的行为，那么你会觉得，这个对象实际上是从别的类实例化而来的。
然而，实际上，你知道我们是在使用组合通过简单引用不同的状态对象来造成类改变的假象。
状态模式的类图
策略模式和状态模式
这两个模式的类图是类似的，它们的差别在于它们的意图。
策略模式是围绕可以互换的算法来创建成功业务的，而状态模式通过改变对象内部的状态来帮助对象控制自己的行为。
策略模式中，客户通常主动指定Context所要组合的策略对象时哪一个。
策略模式让我们具有弹性，能够在运行时改变策略，但对于某个context对象来说，通常都只有一个最适当的策略对象。
状态模式中，我们将一群行为封装在状态对象中，context的行为随时可以委托到那些状态对象中的一个。
随着时间的流逝，当前状态在状态对象集合中游走改变，以反映出context内部的状态，因此，context的行为也会跟着改变。
但是context的客户对于状态对象了解不多，甚至根本是浑然不觉。
一般来说，我们把策略模式想成是除了继承之外的一种弹性替代方案。如果你使用继承定义了一个类的行为，你将被这个行为困住，甚至要修改它都很难。
有了策略模式，你可以通过组合不同的对象来改变行为。
我们把状态模式想成是不用在context中放置许多条件判断的替代方案。
通过将行为包装进状态对象中，你可以通过在context内简单地改变状态对象来改变context的行为。
