1700473673
Context context=new Context（）；
1700473674
1700473675
context.setLiftState（new ClosingState（））；
1700473676
1700473677
context.open（）；
1700473678
1700473679
context.close（）；
1700473680
1700473681
context.run（）；
1700473682
1700473683
context.stop（）；
1700473684
1700473685
}
1700473686
1700473687
}
1700473688
1700473689
Client场景类太简单了，只要定义一个电梯的初始状态，然后调用相关的方法，就完成了，完全不用考虑状态的变更，运行结果完全相同，不再赘述。
1700473690
1700473691
我们再来回顾一下我们刚刚批判的上一段代码。首先是代码太长，这个问题已经解决了，通过各个子类来实现，每个子类的代码都很短，而且也取消了switch……case条件的判断。其次是不符合开闭原则，那如果在我们这个例子中要增加两个状态应该怎么做呢？增加两个子类，一个是通电状态，一个是断电状态，同时修改其他实现类的相应方法，因为状态要过渡，那当然要修改原有的类，只是在原有类中的方法上增加，而不去做修改。再次是不符合迪米特法则，我们现在的各个状态是单独的类，只有与这个状态有关的因素修改了，这个类才修改，符合迪米特法则，非常完美！这就是状态模式。
1700473692
1700473693
1700473694
1700473695
1700473696
设计模式之禅 [:1700454044]
1700473697
设计模式之禅 26.2 状态模式的定义
1700473698
1700473699
上面的例子中多次提到状态，本节讲的就是状态模式，什么是状态模式呢？其定义如下：
1700473700
1700473701
Allow an object to alter its behavior when its internal state changes.The object will appear to change its class.（当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。）
1700473702
1700473703
状态模式的核心是封装，状态的变更引起了行为的变更，从外部看起来就好像这个对象对应的类发生了改变一样。状态模式的通用类图如图26-5所示。
1700473704
1700473705
1700473706
1700473707
1700473708
图26-5 状态模式通用类图
1700473709
1700473710
我们先来看看状态模式中的3个角色。
1700473711
1700473712
❑State——抽象状态角色
1700473713
1700473714
接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。
1700473715
1700473716
❑ConcreteState——具体状态角色
1700473717
1700473718
每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗地说，就是本状态下要做的事情，以及本状态如何过渡到其他状态。
1700473719
1700473720
❑Context——环境角色
1700473721
1700473722
定义客户端需要的接口，并且负责具体状态的切换。