22. State 状态（行为型模式）

问题的提出：对象状态影响对象行为。对象拥有不同的状态，往往会行使不同的行为…

动机（Motivation）
     在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
   如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？

意图（Intent）
    允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。

例子：

abstract   class  StatedDocument  // 抽象类--表达状态及依赖状态的行为
{
    public abstract void Handle1();
    public abstract void Handle2();
    public abstract void Handle3();

    public abstract StatedDocument Next
    {
        get ;
        set ;
    }
}

class  Document  // 主逻辑
{
    StatedDocument statedDocument;
    public void SetStatedDocument(StatedDocument statedDocument)
    {
        this.statedDocument = statedDocument;    
    }
    public void Handle1()
    {
        statedDocument.Handle1();
        statedDocument = statedDocument.next ;//
    }
    public void Handle2()
    {
        statedDocument.Handle2();
    }
    public void Handle3()
    {
        statedDocument.Handle3();
    }
}

State模式的几个要点
• State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，
切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
• 为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的
情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
• 如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。

讲座中的论点：
//设计模式的目的在于避免编译时依赖，获得运行时依赖
//如果不是有意识的去往某个方向提升，可能写了很多代码，写来写去还是同一水平。
//设计就是源代码，源代码就是设计
//软件的特点：在没有写代码的前期把需求确定。
//敏捷软件开发过程的思想：边走边看。
//项目的前期在拼命重视设计，项目后期不管设计了。正常的应该是后期重视设计，因为前期对需求了解不深，后期对需求了解深。