状态模式

前言 在实际开发中，我们经常会遇到这种情况；一个对象有多种状态，在每一个状态下，都会有不同的行为。那么在代码中我们经常是这样实现的。 typedef enum tagState { state, state1, state2 }State; void Action(State actionState) { if (actionState == state) { // DoSomething } else if (actionState == state1) { // DoSomething } else if (actionState == state2) { // DoSomething } else { // DoSomething } } 而这种就好比 简单工厂模式 ，当我们增加新的状态类型时，我们又需要修改原来的代码，这种对于测试是很不利的；由于简单工厂的缺点那么的明显，后来的工厂模式就克服了这个缺点，我们就可以借鉴工程模式，来解决这种随着状态增加而出现的多分支结构，而这就是我今天要总结的状态模式。 状态模式 在GOF的《设计模式:可复用面向对象软件的基础》一书中对状态模式是这样说的：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。状态模式的重点在于状态转换，很多时候，对于一个对象的状态，我们都是让这个对象包含一个状态的属性

《敏捷软件开发》读书笔记（3） 书中设计模式的汇总 命令类模式，分离执行和定义 CMD模式 其实是事件-事务绑定的模型： 可以用事件驱动，只要收到事件，执行绑定到事件对应的CMD对象.do方法就行，对于真正执行的事情无感知。解除了系统的逻辑互联关系和实际连接关系的设备之间的耦合。 事务型操作，把验证和执行分离，由执行框架完成验证和执行操作。解除了获取数据、验证数据、执行数据操作这种空间耦合，同时也可以在执行时间上进行解耦。扩展可以增加undo接口，系统把CMD对象压入堆栈，在进行回退的时候调用undo。 整体上就是把程序算法或者业务逻辑，和程序的实际控制执行解耦，有点像函数式编程。 ACTIVE OBJECT模式 这部分没看懂，似乎是多线程任务执行引擎，可以把CMD对象放回到引擎列表中。这种类型的线程任务是RTC线程。 复用算法，分离业务逻辑的模式 TEMPLATE METHOD模式 把算法的控制和逻辑分离，通用算法封装到基类，不需要理解的逻辑部分交给子类实现，比如冒泡排序。（其实不一定用继承，可以用组合），注意防止滥用。 STRATEGY模式 相比TEMPLATE METHOD，更好的解除了具体实现和算法的耦合，使用接口+组合，而不是继承，能提高具体实现的复用性，优先使用。 统一对外接口，隐藏策略的模式 FACADE模式 封装组件对外的策略和约束

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、类图 状态模式与策略模式的类图一样的，唯一不同，名字不同（Strategy->State） 参考我写的策略模式 二、模式含义 Context（环境类）：环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同，因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象。 State（抽象状态类）：它用于定义一个接口以封装与环境类的一个特定状态相关的行为，在抽象状态类中声明了各种不同状态对应的方法，而在其子类中实现类这些方法，由于不同状态下对象的行为可能不同，因此在不同子类中方法的实现可能存在不同，相同的方法可以写在抽象状态类中。 ConcreteState（具体状态类）：它是抽象状态类的子类，每一个子类实现一个与环境类的一个状态相关的行为，每一个具体状态类对应环境的一个具体状态，不同的具体状态类其行为有所不同。 三、总结 状态模式将一个对象在不同状态下的不同行为封装在一个个状态类中，通过设置不同的状态对象可以让环境对象拥有不同的行为，而状态转换的细节对于客户端而言是透明的，方便了客户端的使用。在实际开发中，状态模式具有较高的使用频率

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 忏悔时间：我有点过分了在这章塞下太多东西。表面我是讨论状态模式，但是我不可能在讨论这个时不涉及到更基本的有限状态机（FSM）的概念。一旦我讲到那了，我发现我又不得不介绍分层状态机（hierarchical state mechine）和下推自动机（pushdown automata）。 要讲的东西太多了，所以为了使篇幅尽可能短，一些代码例子省略了一些细节，这些需要你自己补全。我希望这些仍然是简单清晰的使你了解框架。 不要感到悲伤如果你没听过状态机。熟知AI和编译器的程序员，也对其他圈子不甚了解。我认为他们了解的比较广了，所以我这次抛给他们一个不一样的问题。 We've all been there 我们做一个横版小游戏。我们的工作是实现玩家控制的女英雄。这意味着要使其响应玩家的输入。按下“B”，她应该跳起来。很简单： void Heroine::handleInput(Input input) { if (input == PRESS_B) { yVelocity_ = JUMP_VELOCITY; setGraphics(IMAGE_JUMP); } } 找到bug了没？ 没有任何阻止“空中跳”的条件-当她在空中时不断地敲击“B”键，然后她就会一直漂浮在空中

优化 if else 参考： 《阿里巴巴java编码规范》、《设计模式》（清华大学出版）、https://blog.csdn.net/mifffy_java/article/details/95201289 1、 阿里编程归约 对于控制语句，阿里归约上推荐了一种思路。【推荐】在表达异常的分支时，尽量少用 if else 方式，这种方式可以改写成： if ( condition ) { . . . return obj ; } // 接着写 else 的业务逻辑代码 说明：如果不得不使用 if()...else if()...else... 方式表达逻辑， 【强制】避免后序代码维护困难，请勿超过3层。 正例：超过3层的 if else 逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，其中卫语句示例如下： public void today ( ) { if ( isBusy ( ) ) { System . out . println ( "change time." ) ; return ; } if ( isFree ( ) ) { System . out . println ( "go to travel." ) ; return ; } Sysout . out . println ( "stay at home. learning java." ) ;

本章节我们来学习状态模式，什么是状态，世间万事万物都有状态说法，状态是人或事物表现出来的形态。这个词大概的意思就是这样，状态在生活中随处都有，比如水的状态有固态（冰），液态、气态等状态，有比如汽车有运行状态、停止状态、故障状态等。。。接下来我们来看看状态模式的定义：**当一 个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类，状态模式的核心是封装，状态的变更引起了行为的变更，从外部看起来就好像这个对象对应的类发生了改 变一样。**这句话什么意思呢？其实是再说，对象的行为跟其状态密切相关，举例说明，如汽车在故障的状态下不能运行这就是 运行这个行为跟故障状态的密切关系。接下来我们看看状态模式的通用类图： ● State——抽象状态角色 接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。 ● ConcreteState——具体状态角色 每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗地说，就是本状态下要做 的事情，以及本状态如何过渡到其他状态。 ● Context——环境角色 定义客户端需要的接口，并且负责具体状态的切换。 伪代码： status： ConcreteState1： ConcreteState2： Context ： client： 案例：我们使用电梯来举例子，我们先看看电梯的状态跟行为的关系： 此案例类图如下： 代码结构：

在软件开发过程中，应用程序中的有些对象可能会根据不同的情况做出不同的行为，我们把这种对象称为有状态的对象，而把影响对象行为的一个或多个动态变化的属性称为状态。当有状态的对象与外部事件产生互动时，其内部状态会发生改变，从而使得其行为也随之发生改变。如人的情绪有高兴的时候和伤心的时候，不同的情绪有不同的行为，当然外界也会影响其情绪变化。 对这种有状态的对象编程，传统的解决方案是：将这些所有可能发生的情况全都考虑到，然后使用 if-else 语句来做状态判断，再进行不同情况的处理。但当对象的状态很多时，程序会变得很复杂。而且增加新的状态要添加新的 if-else 语句，这违背了“开闭原则”，不利于程序的扩展。 以上问题如果采用“状态模式”就能很好地得到解决。状态模式的解决思想是：当控制一个对象状态转换的条件表达式过于复杂时，把相关“判断逻辑”提取出来，放到一系列的状态类当中，这样可以把原来复杂的逻辑判断简单化。 状态模式的定义与特点 状态（State）模式的定义：对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。 状态模式是一种对象行为型模式，其主要优点如下。 状态模式将与特定状态相关的行为局部化到一个状态中，并且将不同状态的行为分割开来，满足“单一职责原则”。 减少对象间的相互依赖

1. 概述 　　当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 2. 解决的问题 　　主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同的一系列类当中，可以把复杂的逻辑判断简单化。 3. 模式中的角色 　　3.1 上下文环境（Context）：它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理。 　　3.2 抽象状态（State）：定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。 　　3.3 具体状态（Concrete State）：实现抽象状态定义的接口。 4. 模式解读 　　4.1 状态模式的类图 　　 　　4.2 状态模式的代码实现 /// <summary> /// Context类，维护一个ConcreteState子类的实例，这个实例定义当前的状态。 /// </summary> public class Context { private State state; /// <summary> /// 定义Context的初始状态 /// </summary> /// <param name="state"></param> public Context(State state) { this.state =

状态模式 概述： 当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化 。 意图： 允许一个对象在其内部状态改变时改变它的行为 结构图： 举例： 在日常生活中最为熟悉的点灯开关，按一下开灯，在按一下关灯，我们用代码来实现这种效果。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 /// <summary> /// 它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理。 /// </summary> public class Context { private AbstractState _state; public AbstractState State { get { return _state;} set { _state=value;} } /

状态模式 概述： 当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化 。 意图： 允许一个对象在其内部状态改变时改变它的行为 结构图： 举例： 在日常生活中最为熟悉的点灯开关，按一下开灯，在按一下关灯，我们用代码来实现这种效果。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 /// <summary> /// 它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理。 /// </summary> public class Context { private AbstractState _state; public AbstractState State { get { return _state;} set { _state=value;} } /