状态模式

认识观察者模式 我们看看报纸和杂志的订阅是怎么回事： 1 、报社的业务就是出版报纸 2 、向某家报社订阅报纸，只要他们有新报纸出版，就会给你送来。只要你是他们的订户，你就会一直收到新报纸 3 、当你不想再看报纸的时候，取消订阅，他们就不会再送新报纸来 4 、只要报社还在运营，就会一直有人（或单位）向他们订阅报纸或取消订阅报纸 出版者 + 订阅者 = 观察者模式 如果你了解报纸的订阅是怎么回事，其实就知道观察者模式是怎么回事，只是名称不太一样：出版者改称为“主题” (Subject) ，订阅者改称为 " 观察者 "(Observer) 1 、主题对象管理某些数据 2 、当主题内的数据改变就会通知观察者 3 、一旦数据改变，新的数据会以某种形式送到观察者手上 4 、观察者订阅（注册）主题以便在主题数据改变时能够收到更新 5 、某个对象不是观察者，所以在主题数据改变使不会被通知 观察者的一天 1 、鸭子对象过来告诉主题，它相当一个观察者 2 、鸭子其实想说的是：我对你的数据改变感兴趣，一有变化请通知我 3 、鸭子对象现在已经是正式的观察者了 4 、鸭子静候通知，等待参与这项伟大的事情。一旦接获通知，就会得到一个整数 5 、主题有了新的数据值 6 、现在鸭子和其他所有观察者都会收到通知：主题已经改变了 7 、老鼠对象要求从观察者中把自己除名 8 、老鼠已经观察此主题太久，厌倦了

1、状态模式简介 1.1>、定义 　　状态模式的核心思想是允许一个对象在它的内部状态改变时改变它的行为，即不同的状态对应不同的行为。 　　状态模式的针对性很强，当有状态变化的时候可以选择状态模式。 1.2>、使用频率 　　 中等 2、状态模式结构 2.1>、结构图 2.2>、参与者 　　状态模式参与者： 　　◊ Context：状态管理器 　　　　° 定义对Client感兴趣的接口 　　　　° 维持一个ConcreteState子类的实例，这个实例定义当前状态 　　◊ State：状态，定义一个接口以封装与Context的一个特定状态相关的行为。 　　◊ ConcreteState：具体状态子类，每一子类实现的一个与Context的一个状态相关的行为。 3、状态模式结构实现 　　State.cs using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace DesignPatterns.StatePattern.Structural { public abstract class State { public abstract void Handle(Context context); } } 　　Context.cs using System;

状态模式 在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。 在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。 介绍 意图： 允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。 主要解决： 对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。 何时使用： 代码中包含大量与对象状态有关的条件语句。 如何解决： 将各种具体的状态类抽象出来。 关键代码： 通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。 应用实例： 1、打篮球的时候运动员可以有正常状态、不正常状态和超常状态。 2、曾侯乙编钟中，'钟是抽象接口','钟A'等是具体状态，'曾侯乙编钟'是具体环境（Context）。 优点： 1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4

“人有悲欢离合，月有阴晴圆缺”，包括人在内，很多事物都具有多种状态，而且在不同状态下会具有不同的行为，这些状态在特定条件下还将发生相互转换。就像水，它可以凝固成冰，也可以受热蒸发后变成水蒸汽，水可以流动，冰可以雕刻，蒸汽可以扩散。我们可以用UML状态图来描述H2O的三种状态，如图1所示：在软件系统中，有些对象也像水一样具有多种状态，这些状态在某些情况下能够相互转换，而且对象在不同的状态下也将具有不同的行为。为了更好地对这些具有多种状态的对象进行设计，我们可以使用一种被称之为 状态模式 的设计模式，本章我们将学习用于描述对象状态及其转换的状态模式。 图1 H 2 O的三种状态（未考虑临界点） 在软件系统中，有些对象也像水一样具有多种状态，这些状态在某些情况下能够相互转换，而且对象在不同的状态下也将具有不同的行为。为了更好地对这些具有多种状态的对象进行设计，我们可以使用一种被称之为 状态模式 的设计模式，本章我们将学习用于描述对象状态及其转换的状态模式。 银行系统中的账户类设计 Sunny软件公司欲为某银行开发一套信用卡业务系统，银行账户(Account)是该系统的核心类之一，通过分析，Sunny软件公司开发人员发现在该系统中，账户存在三种状态，且在不同状态下账户存在不同的行为，具体说明如下： (1) 如果账户中余额大于等于0，则账户的状态为正常状态(Normal State)

状态模式就是将状态的条件判断语句转化成其函数重写形式，利用了面向对象语言的多态性，本文根据https://blog.csdn.net/lm324114/article/details/78819602的情景将状态模式用Matlab语言实现。 根据上图情景，用传统的方法实现如下： RoomState.m classdef RoomState < handle enumeration FREE BOOKED CHECKIN end end IfRoom.m classdef IfRoom < handle properties state; end methods function obj = IfRoom() obj.state = RoomState.FREE; end function bookRoom(obj) switch obj.state case RoomState.FREE disp('完成预订...'); obj.state = RoomState.BOOKED; case RoomState.BOOKED disp('该房间已经被预订了...'); case RoomState.CHECKIN disp('该房间已经有人入住了...'); end end function checkInRoom(obj) switch obj.state case

在介绍状态模式之前，我们先来看这样一个实例：你公司力排万难终于获得某个酒店的系统开发项目，并且最终落到了你的头上。下图是他们系统的主要工作(够简单)。 当你第一眼看到这个系统的时候你就看出来了这是一个状态图，每个框框都代表了房间的状态，箭头表示房间状态的转换。分析如下：房间有三个状态：空闲、已预订、已入住，状态与状态之间可以根据客户的动作来进行转换。定义每个状态的值。 public static final int FREEMTIME_STATE = 0; //空闲状态 public static final int BOOKED_STATE = 1; //已预订状态 public static final int CHECKIN_STATE = 2; //入住状态 int state = FREEMTIME_STATE; //初始状态 通过客户的动作将每个状态整合起来，对于这个“最简单”的方式肯定是if…else if…else啦！所以这里我们就通过动作将所有的状态全面整合起来。分析得这里有四个动作：预订、入住、退订、退房。如下： /** * @desc 预订 * @return void */ public void bookRoom(){ if(state == FREEMTIME_STATE){ //空闲可预订 if(count > 0){ System.out

6 状态模式总结 状态模式将一个对象在不同状态下的不同行为封装在一个个状态类中，通过设置不同的状态对象可以让环境对象拥有不同的行为，而状态转换的细节对于客户端而言是透明的，方便了客户端的使用。在实际开发中，状态模式具有较高的使用频率，在 工作流和游戏开发 中状态模式都得到了广泛的应用，例如公文状态的转换、游戏中角色的升级等。 1. 主要优点 状态模式的主要优点如下： (1) 封装了状态的转换规则 ，在状态模式中可以将状态的转换代码封装在环境类或者具体状态类中，可以对状态转换代码进行集中管理，而不是分散在一个个业务方法中。 (2) 将所有与某个状态有关的行为放到一个类中 ，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为。 (3) 允许状态转换逻辑与状态对象合成一体，而不是提供一个巨大的条件语句块 ，状态模式可以让我们避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起。 (4) 可以 让多个环境对象共享一个状态对象 ，从而减少系统中对象的个数。 2. 主要缺点 状态模式的主要缺点如下： (1) 状态模式的使用 必然会增加系统中类和对象的个数，导致系统运行开销增大 。 (2) 状态模式的结构与实现都较为复杂， 如果使用不当将导致程序结构和代码的混乱，增加系统设计的难度 。 (3) 状态模式 对“开闭原则”的支持并不太好 ，增加新的状态类需要修改那些负责状态转换的源代码

享元模式结构较为复杂，一般结合工厂模式一起使用，在它的结构图中包含了一个享元工厂类，其结构图如图 14-3 所示： 图 14-3 享元模式结构图 在享元模式结构图中包含如下几个角色： ● Flyweight （抽象享元类）：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态），同时也可以通过这些方法来设置外部数据（外部状态）。 ● ConcreteFlyweight （具体享元类）：它实现了抽象享元类，其实例称为享元对象；在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象。 ● UnsharedConcreteFlyweight （非共享具体享元类）：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类；当需要一个非共享具体享元类的对象时可以直接通过实例化创建。 ● FlyweightFactory （享元工厂类）：享元工厂类用于创建并管理享元对象，它针对抽象享元类编程，将各种类型的具体享元对象存储在一个享元池中，享元池一般设计为一个存储“键值对”的集合（也可以是其他类型的集合），可以结合工厂模式进行设计；当用户请求一个具体享元对象时，享元工厂提供一个存储在享元池中已创建的实例或者创建一个新的实例（如果不存在的话）

功能 允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类 解决 主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为 何时使用：代码中包含大量与对象状态有关的条件语句 如何解决：将各种具体的状态类抽象出来 关键代码：状态模式的接口中有一个或者多个方法 优缺点 优点： 封装了转换规则 枚举可能的状态，在枚举状态之前需要确定状态种类 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数 缺点： 状态模式的使用必然会增加系统类和对象的个数 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱 状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码 应用场景 应用实例：打篮球的时候运动员可以有正常状态、不正常状态和超常状态 使用场景： 行为随状态改变而改变的场景 条件、分支语句的代替者 注意事项：在行为受状态约束的时候使用状态模式，而且状态不超过 5 个 简单示例代码部分 State.hpp # ifndef

第一章节 工厂模式 1.面向对象的好处？ 2.UML图 3.简述简单工厂模式   假如我们需要写一个加减乘除的计算器程序，如果使用面向过程的思维来解决这个问题，一旦我们修改了其中某些需求（比如增加开根号的运算），那么我们就会关于运算部分的代码，这对于一些系统来说是很有风险的操作。也不符合面向对象的封装的方法。   我们可以把界面和运算进行分层出来，界面类处理界面的事情，运算类只处理运算逻辑。这样是非常可以扩展的，如果我们需要增加一种运算，我们只需要多写一个运算类继承运算基类。   如何让计算机知道你将要使用哪个运算类呢？及对象的实例化问题，到底要实例化谁，未来会不会增加实例化对象，这些很容易变化的部分。我们可以使用一个单独的类来做这个创造实例的过程，这就是工厂。 编程是一门技术，更加是一门艺术 第二章节 策略模式 1.商场促销问题   比如商场打不同的折扣,双十一打五折，公司周年庆打四折，每周五打八折。商场不仅仅有打折问题，还有 满多少返现多少，比如满300返现100。商场积分问题，100块可以积10分。这一系列的问题，都应考虑到，不可能每次都要去修改代码后重新编译部署。这就是一个策略问题。   对于打折问题，以前学过简单工厂，我们可以写一个基类，然后打不同的折扣去继承这个基类，这样写不符合面向对象封装的方法。不管打多少折都是打折，没必要写那么多的类。 2.策略模式    策略模式