状态模式

Behavioral(行为模式) Chain of responsibility: 把一个对象在一个链接传递直到被处理。在这个链上的所有的对象有相同的接口（抽象类）但却有不同的实现。 java.util.logging.Logger#log() javax.servlet.Filter#doFilter() Command: 把一个或一些命令封装到一个对象中。 java.lang.Runnable javax.swing.Action Interpreter: 一个语法解释器的模式。 java.util.Pattern java.text.Normalizer java.text.Format Iterator: 提供一种一致的方法来顺序遍历一个容器中的所有元素。 java.util.Iterator java.util.Enumeration Mediator: 用来减少对象单的直接通讯的依赖关系。使用一个中间类来管理消息的方向。 java.util.Timer java.util.concurrent.Executor#execute() java.util.concurrent.ExecutorService#submit() java.lang.reflect.Method#invoke() Memento: 给一个对象的状态做一个快照

观察者模式（Observer）：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。 UML类图： 分析： Observer类，抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时，更新自己这个接口叫做更新接口。抽象观察者一般用一个抽象类或者一个接口实现。更新接口通常包含一个 Update方法，这个方法叫做更新方法。 Subject类，可翻译为主题或者抽象通知者，一般用一个抽象类或者一个接口实现。它把所有对观察者对象的引用，保存在一个聚集里，每个主题都可以有任意数量的观察者。抽象主题提供一个接口，可以增加和删除观察者对象。 ConcreteSubject类叫做具体主题或者具体通知者，将有关状态存入具体观察者对象：在具体主题的内部状态得到改变时，给所有登记过的观察者发出通知。具体主题通常用一个具体子类实现。 ConcreteObserver类，具体观察者，实现抽象观察者角色所要求的更新接口。以便使本身的状态与主题的状态相协调。具体观察者角色可以保存一个指向具体主题对象的引用，具体 观察者角色通常由一个具体子类实现。 观察者模式（Observer）实现： [csharp] view plain copy print ? using System; using System

面向对象软件工程知识点 1．封装是指把对象的（A）结合在一起，组成一个独立的对象。 A．属性和操作 B．信息流 C．消息和事件 D．数据的集合 2．状态图和活动图建立了UML面向对象开发过程中的对象动态（B）模型。 A．交互 B．状态 C．体系结构 D．软件复用 3．UML的（C）模型图由活动图、顺序图、状态图和合作图组成。 A．用例 B．静态 C．动态 D．系统 4．在UML的需求分析建模中，对用例模型中的用例进行细化说明应使用（A）。 A．活动图 B．状态图 C．配置图 D．构建图 5．设计模式就是对（D）的描述或解决方案，往往直接对应一段程序代码。 A．某个构件 B．成熟的设计 C．一个用例 D．特定问题 6．类和对象都有属性，它们的差别是：类描述了属性的类型，而对象的属性必须有（C）。 A．正负号 B．动作 C．具体值 D．私有成员 7．顺序图的模型元素有（A）、消息、生存线、激活期等，这些模型元素表示某个用例中的若干个对象和对象之间所传递的消息，来对系统的行为建模。 A．对象 B．箭头 C．活动 D．状态 8．状态图可以表现（B）在生存期的行为、所经历的状态序列、引起状态转移的事件以及因状态转移而引起的动作。 A．一组对象 B．一个对象 C．多个执行者 D．几个子系统 9．使得在多个类中能够定义同一个操作或属性名，并在每一个类中有不同的实现的一种方法是（B）。 A．继承

模式介绍 在状态模式(State Pattern)中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的Context对象。 模式优点 1、允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。 2、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 3、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 4、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。 模式缺点 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态。 使用场景 1、行为随状态改变而改变的场景。 2、条件、分支语句的代替者。 系统建模 1、创建一个State接口和实现了State接口的实体状态类。Context是一个带有某个状态的类。 2、客户端类使用Context和State对象来演示Context在状态改变时的行为变化。 系统实现 /** * Context类 */ public class Context

前言 在实际开发中，我们经常会遇到这种情况；一个对象有多种状态，在每一个状态下，都会有不同的行为。那么在代码中我们经常是这样实现的。 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的《设计模式:可复用面向对象软件的基础》一书中对状态模式是这样说的：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。状态模式的重点在于状态转换，很多时候，对于一个对象的状态，我们都是让这个对象包含一个状态的属性

观察者模式 在GOF的《设计模式:可复用面向对象软件的基础》一书中对观察者模式是这样说的：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。当一个对象发生了变化，关注它的对象就会得到通知；这种交互也称为发布-订阅(publish-subscribe)。目标是通知的发布者，它发出通知时并不需要知道谁是它的观察者。 再说说上面的数据和图之间的关系；不管是折线图、饼状图，还是柱状图，它们都依赖于数据；当数据发生变化时，数据对象会通知依赖于它的对象去更新；所以就有了Excel中，当数据发生变化时，对应的统计图也会自动的重绘。 UML类图 Subject（目标） ——目标知道它的观察者。可以有任意多个观察者观察同一个目标； ——提供注册和删除观察者对象的接口。 Observer（观察者） ——为那些在目标发生改变时需获得通知的对象定义一个更新接口。 ConcreteSubject（具体目标） ——将有关状态存入各ConcreteObserver对象； ——当它的状态发生改变时，向它的各个观察者发出通知。 ConcreteObserver（具体观察者） ——维护一个指向ConcreteSubject对象的引用； ——存储有关状态，这些状态应与目标的状态保持一致； ——实现Observer的更新接口以使自身状态与目标的状态保持一致。

边工作边学习，最近做语音模块，老大安排了任务去做语音唤醒实现。自己啪啪啪傻不垃圾的就用最简单的粗鄙方法实现了，老大看了看之后说，可以用状态机模式做的试试，然后就在老大的带领下，学习了状态机颇有收获。 一、什么是状态模式。 官方解释：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类 自己理解：就是外界调用类A对象的某个方法时，当这个方法改变了某种状态，然后就会在这个方法里面切换到对应的状态B类中。 二、看代码理解 2.1 所有状态需要一个管理类。 wakeupEngineManager wakeupEngineManager { public: wakeupEngineManager() : mCurrentStatus(std::make_shared<IdleStatus>(this)) { } bool changeToNotWakeupStates（ ）{ if ( nullptr ！= mCurrentStatus) { mCurrentStatus -> changeToNotWakeupStates(); } } bool changeToWakeuped() { if ( nullptr ！= mCurrentStatus) { mCurrentStatus -> changeToWakeuped(); } } bool changeToIdle

状态模式： 当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了其类。 状态模式主要解决的是当控制一个对象状态转换的条件表达式复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。 简单实现： namespace StateMode { /// <summary> /// State类，抽象状态类，定义一个接口以封装与Context的一个特定状态相关的行为 /// </summary> abstract class State { public abstract void Handle(Context context); } } namespace StateMode { /// <summary> /// Context类，维护一个ConcreteState子类的实例，这个实例定义当前的状态 /// </summary> class Context { private State state; //定义Context的初始状态 public Context(State state) { this.state = state; } //可读写的状态属性，读取当前状态和设置新状态 public State State { get { return state; } set { state = value; Console

前言 前面说了一个状态模式，总结过程中发现和这个责任链的使用场景很类似，都是为了解耦大量复杂逻辑判断的，那么他们有什么不同呢？ 回忆状态模式—— 策略模式的孪生兄弟——对状态模式的深度复习总结 ：状态模式允许通过改变对象的内部状态而改变对象自身的行为，这个对象表现得就好像修改了它的类一样。 状态模式的关键是各个状态子类必须知道下一个状态是什么 ， 且要把逻辑判断转移到各个状态子类中，客户端不需要了解状态迁移的顺序。 状态模式虽然类图和策略模式几乎一样，但是策略模式的目的是针对单一算法，在运行时能替换，客户端需要事先了解策略，主动去选择合适的策略，不存在状态的自动迁移。 下面总结复习职责链模式。 责任链（职责链，Chain of Responsibility（CoR））概述 责任链，Chain of Responsibility（CoR），也叫职责链模式或者职责连锁模式，同状态模式一样，也是对象的行为模式之一，该模式构造一系列分别担当不同的职责的类的对象来共同完成一个任务，对象由每一个对象对其下家的引用而连接起来形成一条链，客户端发出的请求在这个链上传递，直到链上的某一个对象决定能处理此请求。 注意：发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任，所以该模式被称作职责链模式。 责任链模式的特点

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。 行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式是 GoF 设计模式 中最为庞大的一类，它包含以下 11 种模式。 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象