adb命令返回的值怎样取出来_不会利用它来减少if else并解耦？来看看这篇文章...

引言

状态模式大家可能初听会很陌生，这种模式有什么用？我就是个CRUD BOY，面对不同的状态，我一个状态一个状态的判断，if else、if else...... 不断的来写不同的逻辑它不香吗？

香！ 但是作为一个杰出的后浪代表，仅仅如此怎能满足我对知识的欲望！

我们知道面向对象的设计模式有七大基本原则：

• 开闭原则(Open Closed Principle，OCP)
• 单一职责原则(Single Responsibility Principle, SRP)
• 里氏代换原则(Liskov Substitution Principle，LSP)
• 依赖倒转原则(Dependency Inversion Principle，DIP)
• 接口隔离原则(Interface Segregation Principle，ISP)
• 合成/聚合复用原则(Composite/Aggregate Reuse Principle，CARP)
• 最少知识原则(Least Knowledge Principle，LKP)或者迪米特法则(Law of Demeter，LOD)

简单理解就是：

• 开闭原则是总纲，它指导我们要对扩展开放，对修改关闭；
• 单一职责原则指导我们实现类要职责单一；里氏替换原则指导我们不要破坏继承体系；
• 依赖倒置原则指导我们要面向接口编程；接口隔离原则指导我们在设计接口的时候要精简单一；
• 迪米特法则指导我们要降低耦合。

设计模式就是通过这七个原则，来指导我们如何做一个好的设计。但是设计模式不是一套“奇技淫巧”，它是一套方法论，一种高内聚、低耦合的设计思想。我们可以在此基础上自由的发挥，甚至设计出自己的一套设计模式。

当然，学习设计模式或者是在工程中实践设计模式，必须深入到某一个特定的业务场景中去，再结合对业务场景的理解和领域模型的建立，才能体会到设计模式思想的精髓。如果脱离具体的业务逻辑去学习或者使用设计模式，那是极其空洞的。

接下来我们将通过业务的实践，来探讨如何用状态设计模式来减少if else，实现可重用、易维护的代码。

状态模式

不知道大家在业务中会不会经常遇到这种情况：

产品：开发哥哥来下，你看我这边想加个中间流程，这个流程是要怎样怎样处理.......，还想区分加了这些操作后的用户，其他不符合这个条件的用户不要影响，能不能实现啊！

我：能啊，加个状态就行啊！于是将原流程加了个状态，当用户处于这个状态时会如何如何......，于是改完上线，过了几天。

产品：开发哥哥再来下，你看我这边想加个中间流程，这个流程是要怎样怎样处理.......，还想区分加了这些操作后的用户，其他不符合这个条件的用户不要影响，能不能实现啊！

我：能啊！内心OS: 咦，似曾相识燕归来，这不是之前加过了一个吗，还加啊！于是吭哧吭哧又给加上了。本想就结束了，但是过了几天，又来问了！于是就不断的if else、if else的来判断装个修改原流程！最终一次不小心，动了下之前状态的代码，悲剧发生了，生产环境报错了！

这是每个开发小哥哥都会遇到的问题，随着业务的不断发展，我们定义表的状态会不断的扩展，状态之间的流转也会越来越复杂，原来的一小块if else代码也会更加的多和杂，着实让人看着摸不着头脑。

那有没有一种模式能让这些业务解耦开，涉及事件的产生和随之产生的影响(状态的流转)。可以先将事件和事件产生后的状态变化绑定起来。不同事件产生的状态流转也是不同的，我们可以从全局的角度来进行配置。

有的！ 当然是我们今天的主角-状态模式了

定义

在状态模式(State Pattern)中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。

在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。

意图

允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。

主要解决

对象的行为依赖于它的状态(属性)，并且可以根据它的状态改变而改变它的相关行为。

何时使用

代码中包含大量与对象状态有关的条件语句。

如何解决

将各种具体的状态类抽象出来。

关键代码

通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。

优点

1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

缺点

1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。

使用场景

1、行为随状态改变而改变的场景。 2、条件、分支语句的代替者。

实际使用代码

说了一堆的概念，大家肯定还是模糊的，那么来这个场景看看吧

场景

作为一个小up，最大的愿望就是自己写的东西能被更多人看到了。投币，点赞，收藏，一键三联的操作大家应该熟悉吧，大家的热情直接影响up的更新频率，那么此时事件和状态就出现了：

• 事件：投币，点赞，收藏
• 状态：SOMETIME(想起来什么时候更新就什么时候更新)，OFTEN(会经常更新下)，USUALLY(有事也更新)，ALWAYS(没停过的肝)

我们可以得到一个关系：

• 投币：UpSometimeState -> UpOftenState
• 点赞：UpOftenState -> UpUsuallyState
• 收藏：UpUsuallyState -> UpAlwaysState
• 英文频率从低到高：Sometime -> Often -> Usually -> Always

了解基本信息后，我们来基于设计模式原则来面向对象开发吧！

代码

我们先定义一个状态的抽象类，用来表示up的更新频率

package cn.guess.statemachine.one;import lombok.Data;/** * @program: guess * @description: up主更新频率状态接口 * @author: xingcheng * @create: 2020-05-10