State模式

状态模式这一章感觉没有读得很懂，主要他的定义什么感觉也没有讲得特别清楚，一开始感觉和策略模式有点像，但是后面反而越看越糊涂了，网上找了一些分析也总感觉差点意思，先这样吧，等整本书看完再回头好好研究研究，说不定有更多的发现。先摘录一下网上我看到比较好的理解。

• 定义:
  很多时候,一个对象的行为会根据一个动态的属性变化而变化,这样的一个对象我们可以称为是有状态的对象。
  那么状态模式就是允许一个对象在其内部状态改变时候去改变对象的行为。 状态模式的关键就是区分其对象内部动态变化状态是什么。
• 归纳分析:
  把变化的属性(状态)封装成不同的类, 并把请求委托给当前的对象状态, 不同的状态此时执行不同的行为
  从使用者角度看, 我们使用的对象在不同状态下有不同的行为, 彷佛这个对象是由不同类实例化而来, 这是因为请求委托的缘故。
• 优点:
  状态模式定义的状态-行为的对应关系, 并将其封装在一个类里面, 我们只需要扩展具体状态类就可以扩展需求。
  避免了Context类的代码无限膨胀和过多的条件分支判断。
  Context类中的请求于具体状态类的行为隔离互补影响。
• 缺点：
  如果状态类很多, 需要不断扩展代码量。
  状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
  状态模式对“开闭原则”的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。
• 状态模式的性能优化点
  管理State对像的创建与销毁: 有两种方式实现

1. 仅仅当Satte对象需要的时候才去创建(节省内存)。这个适合与那些State对象比较庞大的情景。
2. 一开始就创建所有的State对象,适用于State对象不多,以及状态频繁切换使用的情景。
   我们上面的例子是一开始就创建了所有的State对象, 而且是为每一个Context类实例都创建了一组State对象,实际上我们这些State对象是可以在不同的Context类之间进行共享的。

• 适用环境
  对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为。
  代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为，而且这些条件对应于对象的各种状态。