状态模式

原文: C#8.0——异步流（AsyncStream） 异步流（AsyncStream） 原文地址： https://github.com/dotnet/roslyn/blob/master/docs/features/async-streams.md 注意：以下内容最好能根据反编译工具查看异步流相关类生成的代码效果最佳 异步流是可枚举类（Enumerable）的异步变体，它会在遍历下一个元素的时候（Next）会涉及异步操作。只要继承自 IAsyncEnumerable 就能实现。 首先我们来看下这些在 .netcore3.0 新增的异步流 API namespace System.Collections.Generic { public interface IAsyncEnumerable<out T> { IAsyncEnumerator<T> GetAsyncEnumerator(CancellationToken cancellationToken = default); } public interface IAsyncEnumerator<out T> : IAsyncDisposable { T Current { get; } ValueTask<bool> MoveNextAsync(); } } namespace System { public

《java开发手册》中: 况且日常开发时遇到一推的if-else着实让人头疼! so，现在开始改造 一、卫语句 卫语句就是把复杂的条件表达式拆分成多个条件表达式，即代码逻辑先考虑失败、异常、中断、退出等直接返回的情况，以方法多个出口的方式，解决代码中判断分支嵌套的问题，这是逆向思维的体现 比如: if (type == 0) { code... }else if (type == 1) { code... } else if (type == 2) { code... } else { otherCode... } 可以改造为: if (type == 0) { 　　 code... 　　return; } if (type == 1) { 　　 code... 　　return; } if (type == 2) { code... return; } otherCode.... 二、策略模式　 如果不了解策略模式，可以去看下菜鸟教程中的例子，简单明了，地址: https://www.runoob.com/design-pattern/strategy-pattern.html 现在有个需求，根据用户的类型来展示不同的内容，我们将其具体化为一段代码: if ("新客户".equals(userType)) { 　　showNewContent...; }else if(

当一个应用中使用了大量的对象，会造成内存开销大，对象的大部分状态和参数（内部状态）都是相同的时候，可以使用享元模式。使用享元模式可以使这些对象都共享相同的实例。降低存储开销，而对象之间的不同的状态参数(外部状态)则使用外部参数传入来实现。 单纯的享元模式涉及到的角色主要有三个。 抽象享元角色：给出一个抽象接口，以规定具体享元角色需要实现的方法。 具体享元角色：实现抽象享元角色的接口，如果有内蕴状态（具体变量）的话，必须负责为内蕴状态提供存储空间（对其进行保存或者将值赋给新生成一个变量）。 享元工厂：负责创建和管理享元角色。此工厂需保证享元对象可以被系统适当地共享。当一个客户端对象调用一个享元对象的时候，享元工厂角色会检查系统中是否已经有一个符合要求的享元对象。如果已经有了，享元工厂角色就应当提供这个已有的享元对象；如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。 可以发现享元模式是简单工厂模式的包装，只是使用场景不一样。 java总的String类型的变量就是享元模式的实现。 具体实现代码如下： 新建一个抽象享元角色抽象接口： package flyWeight; public interface FlyWeight { public void operate(String s); } 再建一个具体享元角色： package flyWeight;

　状态模式，又称状态对象模式（Pattern of Objects for States），状态模式是对象的行为模式。 状态模式允许一个对象在其内部状态改变的时候改变其行为。 策略模式和状态模式有点相似，区别就是状态模式是行为改变状态，主要在于状态改变行为的应用场景，而策略模式则是采用哪种算法，让Context去实现哪种算法，决定权在于客户端。 状态模式 的行为是 平行的，不可相互替换的 ；而 策略模式 的行为是 平等性的，是可以相互替换的 。 主要有三个角色： 环境角色(Context):保留客户端所需要的一些接口，并保留一个具体状态类的实例。 package design.state; public class Context { private State state; public void setState(State state) { this.state = state; } //定义客户端调用接口 public void request(String para){ state.handle(para); } } 　　 抽象状态角色(State):作为一个接口，封装环境对象的一个特定的状态所对应的行为。 package design.state; public interface State { public void handle(String para); } 　

动机（Motivate） 在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。 如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？ 意图（Intent） 允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。 ——《设计模式》GoF 结构图（Structure） 模式的组成 可以看出，在状态模式的结构图有以下角色： （1）、环境角色（Context）：也称上下文，定义客户端所感兴趣的接口，并且保留一个具体状态类的实例。这个具体状态类的实例给出此环境对象的现有状态。 （2）、抽象状态角色（State）：定义一个接口，用以封装环境对象的一个特定的状态所对应的行为。 （3）、具体状态角色（ConcreteState）：每一个具体状态类都实现了环境（Context）的一个状态所对应的行为。 在状态模式结构中需要理解环境类与抽象状态类的作用： 环境类实际上就是拥有状态的对象，环境类有时候可以充当状态管理器(State Manager)的角色，可以在环境类中对状态进行切换操作。 抽象状态类可以是抽象类，也可以是接口，不同状态类就是继承这个父类的不同子类，状态类的产生是由于环境类存在多个状态，同时还满足两个条件：这些状态经常需要切换

定义 允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。 说明 将状态封装成为独立的类，并将动作委托到代表当前状态的对象。 代码实例 /** * 场景描述：开关电脑状态机。当关闭状态时，按下按钮到开启状态。当开启状态时，按下按钮到关闭状态。 */ /** * 状态封装动作行为 */ interface State { void press(); } /** * 开启状态下的行为 */ class OpenState implements State { private Computer computer; public OpenState(Computer computer) { this.computer = computer; } @Override public void press() { System.out.println("关闭电脑"); computer.setCurrentState(computer.getCloseState()); } } /** * 关闭状态下的行为 */ class CloseState implements State { private Computer computer; public CloseState(Computer computer) { this.computer = computer; }

推荐不错的文章： http://design-patterns.readthedocs.org/zh_CN/latest/behavioral_patterns/state.html#id3 状态模式：当控制对象状态转换的条件或访问的资源过于复杂时，把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断简化。 目标：就是把复杂的判断简化 概念： 有状态的对象：对像取决于一个或者多个动态变化的状态，状态改变时行为也随之改变。 适用情况： 1) • 一个对象的行为取决于它的状态, 并 且它必须在运行时刻根据状态改变它的行为（行为中可能涉及复杂的操作，访问不同模块的对象资源等……）。 2) • 代码中包含大量与对象状态有关的条件语句 3：在有些情况下多个环境对象需要共享同一个状态，在系统中多个环境对象实例共享一个或多个状态对象（一般将这些状态对象定义为环境的静态成员对象） 结构组成： 环境类（客户）： 定义客户感兴趣的接口。维护多个ConcreteState子类的实例，每增加一种状态，环境类就要多增加一个实例。 抽象状态类：定义一组状态转换的算法的接口，让客户来调用接口。 实际情况中，可以将每种状态的子类设置单例或者在子状态类中必须包含上一个状态类的释放和下一个状态类申请。 子状态类中，简化只判断与自己关心的状态变哈，不管全部的状态。if (context.state ==

状态模式 　　 状态模式是对象行为型模式，为了允许一个对象在其内部的状态改变时，修改其行为，这样看起来似乎是修改了它的类一样。状态模式实际上就是统一状态的变化来影响行为，比如一个简单的申请流程，发起-审批-结束，当状态为发起时，该条事务由发起人发起流程；状态为审批时，该条事务变成审批人审批；状态为结束时，该条事务由归档人归档，这个就是状态模式的一种应用。由在我们日常开发时，经常会碰到许多if......else......的情况，同时每个情况里面都需要做复杂的操作，我们会把每个if...else...里面的操作单独抽出来 状态模式的适用性 一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态来改变它的行为。 一个操作中包含大量分支的条件语句，且这些分支依赖于该对象的状态，同时状态分支还有可能继续增加。 状态模式的结构图 状态模式中，总共包含三类角色： 1、环境角色（Context）：定义了客户感兴趣的接口，同时维护了ConcreteState类的实例，这个实例定义了当前状态。 2、抽象状态角色（State）：定义一个接口以封装与Context的一个特定状态相关的行为。 3、具体状态角色（ConcreteState）：每一子类实现一个与Context的一个状态相关的行为。 状态模式示例 　　抽象状态角色，定义状态对应的执行方法 public interface State {

观察者模式 　　 观察者模式是对象行为型模式，它定义了一种一堆多的依赖关系，当一个对象的状态发生改变时，所有依赖于它对象都会得到通知。观察者模式也被成为发布-订阅模式。我们在使用微信的时候订阅公众号，在公众号有心得文章时会推送给订阅公众号的人，在使用微博时，关注了某博主，在我们刷微博同时博主有新的微博时会将新的消息展示给我，这两种案例都是使用了观察者模式。 观察者模式的适用性 观察者模式适用于当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两者封装在独立的对象中以使它们可以各自独立地改变和复用。 观察者模式适用于当改变一个对象时需要立刻改变其他的对象，但是在发生改变时不知道有多少个其他对象需要改变。 观察者模式适用于当必须通知其他对象但是其他对象只有在需要通知时才知道有哪些的情况下。 观察者模式的结构图 观察者模式总共有四类角色： 1、抽象主题角色（Subject）：抽象主题角色保存了它的所有观察者，同时提供了增加、删除观察者，通知观察者观察对象已改变的方法。 2、具体主题角色（ConcreteSubject）：具体主题角色提供了修改合查询状态的方法，同时在修改状态时通知观察者。 3、抽象观察者角色（Observer）：为在目标改变时需获得通知的对象定义一个更新的接口。 4、具体观察者（ConcreteObserver）:维护一个指向ConcreteSubject的引用

行为类模式大PK 行为类模式包括 责任链模式 、 命令模式 、解释器模式、迭代器模式、 中介者模式 、 备忘录模式 、 观察者模式 、 状态模式 、 策略模式 、 模板方法模式 、 访问者模式 。该组设计模式众多，如下我们着重介绍一下命令模式VS策略模式、状态模式VS策略模式、观察者模式VS责任链模式。 命令模式VS策略模式 命令模式和策略模式类图很相似，只是命令模式多了一个接收者（Receiver）角色，通过确切的Command类调用Receiver类，实现了调用者和具体的接收者的解耦。策略模式的意图是封装算法，它认为“算法”已经是一个完整的、不可拆分的原子业务，通过对算法的封装实现算法的独立，并且可以相互转换，让行为的变化独立于拥有行为的客户，如我们在策略模式中的例子：诸葛亮给赵云的锦囊妙计，其中每个计策就是一个算法，对妙计进行封装，在不同的时间调用执行不同的计策；而命令模式是对动作解耦，把一个动作的执行分为执行对象（Receiver）和执行行为（Command），让两者相互独立而不相互影响，我们在命令模式中举出了软件开发的例子，软件开发中包括美工组、界面组、编码组，这就是各个执行对象，还包括一个产品经理，就是那个执行行为，客户通过只跟Command打交道实现各个执行对象的行为。 　　接下来我们从对文件压缩的业务需求出发，分别按照命令模式和策略模式设计出一套实现