状态模式

前言 　　今天我们讲的是状态模式【State Pattern】、这个名字咋一看不好理解，但是仔细一想还是比较容易的。状态模式重点关注的是状态。状态又牵扯着什么呢？房屋的状态暂且可以分为出租、签订合同、退房。那么出租对应的是什么呢？出租状态代表可以租房。可以租房是一个行为了。所以不难理解的是状态模式关注的是状态的改变与行为的变化。 状态模式介绍 一、 来由 　　在软件系统中，经常状态的改变影响着行为的变化。例如房屋状态是出租既可以租房、出售既可以买卖房、不租售意味不可操作。那么如何避免对象操作和状态转换之间出现紧耦合呢？状态模式将每种状态对应的行为抽象出来成为单独新的对象，这样状态的变化不再依赖于对象内部的行为正解决了此问题。 二、 意图 　　允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。 三、 案例图 四、 状态模式代码示例 我们看下案例图中主要三个部分： 环境角色： 包含保留了一个具体状态的实例、给出当前状态及调用方法。 抽象状态： 定义接口、封装一个状态相对应的行为方法。 具体状态： 实现具体状态对应的的具体对应行为。 我们继续看这个房屋的案例，针对房屋我们整理这么一个案例，租房然后签订合同。合同半年内退房无押金。租房时间达到半年退房可得押金。我们看下代码实现吧 : namespace State_Pattern { /// <summary> ///

状态模式总结篇 状态模式总结篇，我们将从以下几个方面对状态模式进行总结。 状态模式出现的意图是什么？ 通过对象内部状态发生改变进而来改变对象的行为，对象看起来好像是被修改了一样。如，没有糖果的时候(是一个状态)，糖果机就不能运行了，有糖果之后(另一个状态)，投币就可以出糖果了。 本文出处凯哥Java(kaigejava)讲《23种设计模》系列教程种的《状态模式总结篇》 凯哥公众号：凯哥Java 凯哥个人博客：www.kaigejava.com 主要解决的问题是什么？ 对象的行为依赖于对象的状态变化(属性变更)，并且根据属性值(状态)的改变而改变相关的行为。如，出不出糖果这个行为受糖果机里面有没有糖果和有没有投币这两个状态影响而改变的。 什么时候或者是什么场景下使用状态模式？ 在我们的程序代码中包含和很多与对象状态有关的条件语句(如if……else……或者是switch等)的时候，就可以使用状态模式 如何实现状态模式？ 将代码中的各种具体的状态抽象到一个类中。这样就有了状态类抽象对象。 使用状态模式的关键点是什么？ 需要和命令模式进行区分。命令模式的接口中，通常情况下只有一个方法，而状态模式的接口中有一个或者多个方法。还有一个不同的地方就是，状态模式的时候其实现类的方法一般是返回一个值或者是改变变量的值的。这是因为，状态模式一般和对象的状态有关。 状态模式的优缺点： 优点： 1

第一、状态模式定义 状态模式允许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样。 第二、状态模式应用场景 1.一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为。 2.操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。 通常 ,有多个操作包含这一相同的条件结构。State模式将每一个条件分支放入一个独立的类中。 这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。 第三、状态模式实现代码 3.1需要重构代码 public String orderState(String state) { if (state.equals("0")) { return "已经发货"; } if (state.equals("1")) { return "正在运送中...调用第三方快递接口 展示 运送信息"; } if (state.equals("2")) { return "正在派送中... 返回派送人员信息"; } if (state.equals("3")) { return "已经签收，提示给用户快递员评价"; } if (state.equals("4")) { return "拒绝签收， 重新开始申请退单"; } if (state

行为型模式(Behavioral Pattern) 职责链模式(Chain of Responsibility) 多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系， 将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止 典型应用：servlet filter 命令模式(Command) 命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式 将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化； 对请求排队或者记录请求日志，以及支持可撤销的操作。 命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开 五个角色： Command: 抽象命令类 ConcreteCommand: 具体命令类：持有一个接受者Receiver的引用，绑定一个特定的操作 Invoker: 调用者 Receiver: 命令接收者 Client:客户类 //抽象命令 public interface Command { void execute(); } //具体命令：开灯 public class LightOnCommand implements Command { private Light light; public LightOnCommand(Light light) { this

观察者<Observer>模式（有时又被称为发布-订阅<Publish/Subscribe>模式、模型-视图<Model/View>模式、源-收听者<Source/Listener>模式或从属者<Dependents>模式）是软件设计模式的一种。在此种模式中，一个目标物件管理所有相依于它的观察者物件，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实作事件处理系统 Subject （被观察的对象接口） 规定 ConcreteSubject 的统一接口； 每个 Subject 可以有多个 Observer ； ConcreteSubject （具体被观察对象） 维护对所有具体观察者的引用的列表； 状态发生变化时会发送通知给所有注册的观察者。 Observer （观察者接口） 规定 ConcreteObserver 的统一接口； 定义了一个 update() 方法，在被观察对象状态改变时会被调用。 ConcreteObserver （具体观察者） 维护一个对 ConcreteSubject 的引用； 特定状态与 ConcreteSubject 同步； 实现 Observer 接口，通过 update() 方法接收 ConcreteSubject 的通知。 模式的应用场景和优缺点： 观察者模式的应用场景： 1 、对一个对象状态的更新

在上一次的文章里，我们看到，需求的变更，迫使我们需要重新改造现有的糖果机代码来符合这个新提的需求。但是，也并没有难倒我们，至少我们在文末给出了思路和类图，不知道你想的怎么样了呢。 我们不来虚的，直接进入正题，开启我们的学习之旅。 实现我们的状态类 现在是实现一个状态的时候了：我们知道我们要的行为是什么，我们只需要把它变成代码。我们打算完全遵守所写下的状态机代码，但是这一次是分散在不同的类中。比如我们以NoQuarterState类为例。 public class NoQuarterState implements State { GumballMachine gumballMachine; public NoQuarterState(GumballMachine gumballMachine) { this.gumballMachine = gumballMachine; } public void insertQuarter() { System.out.println("You inserted a quarter"); gumballMachine.setState(gumballMachine.getHasQuarterState()); } public void ejectQuarter() { System.out.println("You haven't

定义 表示作用于某对象结构中的各元素的操作。它可以使你在不改变各元素的类的前提下定义作用于这些元素的新操作 [引用大话设计模式概念] 维护了开放-封闭原则（拓展开放，更改封闭） 应用场景 适用于数据结构相对稳定的系统 例：1. apt（注解处理工具）通过访问者模式解析注解（参照Think in Java P632）；2.大话设计模式中，男人和女人对待不同状态做出不同相应的例子 优缺点 优点 处理与数据结构分离（解耦合） ps: 这里的数据结构举例：人类中只有男人女人，男人和女人就是人类的数据结构 使用双分派 增加新的操作时，只需要增加新的访问者，无需改动其他代码（可参照下例代码） 客户端调用时，调用元素的 accept 方法，具体访问者作为参数 accept 方法中，调用访问者的方法，并将自己（具体元素）作为参数传入 增加新的访问者（新的操作）很容易， 缺点 增加新的数据结构会很困难 例如，人类中增加一个种类，那么所有的访问者都要增加一个对此种类的处理 类图 访问者模式类图.jpg 类图中有四个重要元素： Visitor 、 ConcreteVisitor 、 Element 、 ConcreteElement 抽象访问者（Visitor）：为每个 Element 的实现声明一个 Visit （访问）操作，可为接口或抽象类 具体访问者（ConcreteVisitor）

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。 常用应用场景： 工厂模式 ：IOC就是典型的工厂模式 代理模式 ：AOP就是代理实现的 Facade模式 ：shiro框架的核心 单例模式 Spring默认就是单例 不变模式 string 八大基本数据类型都是单例 Future 模式 异步调用。即请求时只拿到一个契约，约定以后可以获取这个东西 来源： https://www.cnblogs.com/duguangming/p/11407721.html

状态模式 允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。 简单的解释一下： 第一部分的意思是将状态封装成独立的类，并将请求委托给当前的状态对象，当对象的内部状态改变时，会带来不同的行为变化。 第二部分是从客户的角度来看，我们使用的对象，在不同的状态下具有截然不同的行为，这个对象看起来是从不同的类中实例化而来的，实际上这是使用了委托的效果。 现在举一个网上比较多的例子，没错就是电灯的例子（不要烦，请耐心往下看） // 首先定义了一个Light类 class Light { // 定义一个状态变量 constructor(){ this.state = 'off' } // 定义一个改变状态的方法 change(){ if(this.state === 'off'){ console.log('开灯') this.state = 'on' } else { console.log('关灯') this.state = 'off' } } } // 创建实例 let light = new Light() // 调用方法 light.change() 当当当当，到此我们已经编写了一个状态机，逻辑简单又缜密，看起来还有那么点无懈可击。 BUT ，你懂的事实并非如此，人生也没那么多的如意。随着人类的进步，需求也不（de） 断（cuo） 进（jin） 步（chi）(●

State模式的定义 State模式的定义 : 不同的状态,不同的行为;或者说,每个状态有着相应的行为. 何时使用 ? 　　State模式在实际使用中比较多,适合"状态的切换".因为我们经常会使用If elseif else 进行状态切换, 如果针对状态的这样判断切换反复出现,我们就要联想到是否可以采取State模式了. 　　不只是根据状态,也有根据属性.如果某个对象的属性不同,对象的行为就不一样,这点在数据库系统中出现频率比较高,我们经常会在一个数据表的尾部,加上property属性含义的字段,用以标识记录中一些特殊性质的记录,这种属性的改变(切换)又是随时可能发生的,就有可能要使用State. 是否使用? 　　在实际使用,类似开关一样的状态切换是很多的,但有时并不是那么明显,取决于你的经验和对系统的理解深度. 　　这里要阐述的是"开关切换状态" 和" 一般的状态判断"是有一些区别的, " 一般的状态判断"也是有 if..elseif结构,例如: if (which==1) state="hello"; else if (which==2) state="hi"; else if (which==3) state="bye"; 　　这是一个 " 一般的状态判断",state值的不同是根据which变量来决定的,which和state没有关系.如果改成: if (state