设计模式（11）——状态模式
1. 定义
??? 状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
??? 要点：
（1）策略模式和状态模式是双胞胎，它们有相同的类图，但是它们的意图不同。策略模式是围绕可以互换的算法来成功创建业务的,然而状态模式是通过改变对象内部的状态来帮助对象控制自己的行为.
（2）Context将与状态相关的操作委托给当前的Concrete State对象处理。
（3）Context可将自身作为一个参数传递给处理该请求的状态对象。这使得状态对象在必要时可访问Context。
（4）Context或Concrete State类都可决定哪个状态是另外哪一个的后继者，以及是在何种条件下进行状态转换。也就是说可以在State中保存对Concrete State的引用，在必要时设置具体的状态，做到状态的转换。
（5）一般来讲，当状态转换是固定的时候，状态转换就适合放在Context中。然而，当转换是更动态的时候，通常会放到具体的状态类中进行。（具体状态类持有Context的引用，实现状态的转换）
2. 类图及描述
图 状态模式类图
?
3. 应用场景及优缺点
??? 适用性：
（1）一个对象的行为取决于它的状态 , 并且它必须在运行时刻根据状态改变它的行为。
（2）一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常，有多个操作包含这一相同的条件结构。 State模式将每一个条件分支放入一独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。
?
??? 效果：
（1）State模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。
State模式将所有与一个特定的状态相关的行为都放入一个对象中。因为所有与状态相关的代码都存在于某一个State子类中, 所以通过定义新的子类可以很容易的增加新的状态和转换。
另一个方法是使用数据值定义内部状态并且让Context操作来显式地检查这些数据。但这样将会使整个Context的实现中遍布看起来很相似的条件语句或case语句。增加一个新的状态可能需要改变若干个操作，这就使得维护变得复杂了。
State模式避免了这个问题,但可能会引入另一个问题,因为该模式将不同状态的行为分布在多个State子类中。这就增加了子类的数目，相对于单个类的实现来说不够紧凑。但是如果有许多状态时这样的分布实际上更好一些 , 否则需要使用巨大的条件语句。正如很长的过程一样，巨大的条件语句是不受欢迎的。它们形成一大整块并且使得代码不够清晰，这又使得它们难以修改和扩展。State模式提供了一个更好的方法来组织与特定状态相关的代码。决定状态转移的逻辑不在单块的 if或switch语句中, 而是分布在State子类之间。将每一个状态转换和动作封装到一个类中，就把着眼点从执行状态提高到整个对象的状态。这将使代码结构化并使其意图更加清晰。
（2）State对象可被共享。如果State对象没有实例变量，即它们表示的状态完全以它们的类型来编码，那么各Context对象可以共享一个 State对象。
?
?
