设计模式（19） 状态模式（简单入门 行为模式）

设计图和源代码请访问我的github：https://github.com/yangsheng20080808/DesignModel

From Now On，Let us begin Design Patterns。

状态模式

定义

当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。 Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

通用类图:



State抽象状态类:定义了一个接口，用以封装环境(Context)对象的一个特定状态的行为。

ConcreteState具体状态类：实现抽象状态接口，实现了一个状态对应的行为。

Context环境类：环境类中维护了一个State对象，它是定义了当前的状态。

状态模式的优点：

结构清晰：避免了过多的条件判断，避免了程序的复杂性，提高了系统的可扩展性。

遵循开闭原则和单一职责原则：每个状态都是一个子类，要增加状态就要增加子类，修改状态，就只需修改一个子类就可以了。

封装性非常好：状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态和行为的变换。

状态模式的缺点：

子类会太多，即类膨胀。这时可以采用状态表，然后根据状态执行相应的操作。如果使用不当将导致程序结构和代码的混乱，对于可以切换状态的状态模式不满足“开闭原则”的要求

状态模式的使用场景：

访问一个聚合对象的内容而无须暴露它的内部表示。

需要为聚合对象提供多种遍历方式。我们只需要实现多个具体的遍历方式用同一个接口。

为遍历不同的聚合结构提供一个统一的接口。

状态模式的注意事项：

状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说行为受状态约束的情况下可以使用状态模式，而且使用时，对象的状态最好不要超过5个。

状态模式的例子：

大家参考一下《设计模式之禅》里面的电梯例子吧。

与策略模式的区别：

状态模式和策略模式的实现方法非常类似，都是利用多态把一些操作分配到一组相关的简单的类中，因此很多人认为这两种模式实际上是相同的。

然而在现实世界中，策略（如促销一种商品的策略）和状态（如同一个按钮来控制一个电梯的状态，又如手机界面中一个按钮来控制手机）是两种完全不同的思想。当我们对状态和策略进行建模时，这种差异会导致完全不同的问题。例如，对状态进行建模时，状态迁移是一个核心内容；然而，在选择策略时，迁移与此毫无关系。另外，策略模式允许一个客户选择或提供一种策略，而这种思想在状态模式中完全没有。

一个策略是一个计划或方案，通过执行这个计划或方案，我们可以在给定的输入条件下达到一个特定的目标。策略是一组方案，他们可以相互替换；选择一个策略，获得策略的输出。策略模式用于随不同外部环境采取不同行为的场合。我们可以参考微软企业库底层Object Builder的创建对象的strategy实现方式。而状态模式不同，对一个状态特别重要的对象，通过状态机来建模一个对象的状态；状态模式处理的核心问题是状态的迁移，因为在对象存在很多状态情况下，对各个business flow，各个状态之间跳转和迁移过程都是及其复杂的。

例如一个工作流，审批一个文件，存在新建、提交、已修改、HR部门审批中、老板审批中、HR审批失败、老板审批失败等状态，涉及多个角色交互，涉及很多事件，这种情况下用状态模式(状态机)来建模更加合适；把各个状态和相应的实现步骤封装成一组简单的继承自一个接口或抽象类的类，通过另外的一个Context来操作他们之间的自动状态变换，通过event来自动实现各个状态之间的跳转。在整个生命周期中存在一个状态的迁移曲线，这个迁移曲线对客户是透明的。我们可以参考微软最新的WWF 状态机工作流实现思想。

在状态模式中，状态的变迁是由对象的内部条件决定，外界只需关心其接口，不必关心其状态对象的创建和转化；

而策略模式里，采取何种策略由外部条件(C)决定。

他们应用场景（目的）却不一样，State模式重在强调对象内部状态的变化改变对象的行为，Strategy模式重在外部对策略的选择，策略的选择由外部条件决定，

也就是说算法的动态的切换。但由于它们的结构是如此的相似，我们可以认为“状态模式是完全封装且自修改的策略模式”。即状态模式是封装对象内部的状态的，而策略模式是封装算法族的