前言：
为什么之前写过Golang 版的设计模式，还在重新写Java版？
答：因为对于我而言，当然也希望对正在学习的大伙有帮助。Java作为一门纯面向对象的语言，更适合用于学习设计模式。
为什么类图要附上uml
因为很多人学习有做笔记的习惯，如果单纯的只是放一张图片，那么学习者也只能复制一张图片，可复用性较低，附上uml，方便有新理解时，快速出新图。
🔥[设计模式Java实现附plantuml源码]专链
- 创建型
- 确保对象的唯一性～单例模式
- 集中式工厂的实现～简单工厂模式
- 多态工厂的实现——工厂方法模式
- 产品族的创建——抽象工厂模式
- 对象的克隆～原型模式
- 复杂对象的组装与创建——建造者模式
- 结构型
- 提供统一入口——外观模式
- 扩展系统功能——装饰模式
- 树形结构的处理——组合模式
- 对象的间接访问——代理模式
- 不兼容结构的协调——适配器模式
- 处理多维度变化——桥接模式
- 实现对象的复用——享元模式
- 行为型
-
请求的链式处理——职责链模式
-
请求发送者与接收者解耦——命令模式
-
遍历聚合对象中的元素——迭代器模式
-
协调多个对象之间的交互——中介者模式
-
对象间的联动～观察者模式
-
撤销功能的实现——备忘录模式
状态模式用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题。当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行为不相同时可以使用状态模式。状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化。对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致性地处理。
:::info
状态模式定义如下：状态模式（State Pattern）：
允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象（Objects for States），状态模式是一种对象行为型模式。
:::
在状态模式中引入了抽象状态类和具体状态类，它们是状态模式的核心，其结构如图所示。
@startuml
class Context {
- state
+ setState(State state)
+ request()
}
note left of Context::request
state.handler()
end note
abstract class State {
+ handler()
}
class ConcreteStateA extends State {
+ handler()
}
class ConcreteStateB extends State {
+ handler()
}
Context *-right-> State: state
@enduml
（1）Context（环境类）：环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同，因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象。
（2）State（抽象状态类）：它用于定义一个接口以封装与环境类的一个特定状态相关的行为。在抽象状态类中声明各种不同状态对应的方法，而在其子类中实现这些方法。由于不同状态下对象的行为可能不同，因此在不同子类中方法的实现可能存在不同，相同的方法可以写在抽象状态类中。
（3）ConcreteState（具体状态类)：它是抽象状态类的子类，每个子类实现一个与环境类的一个状态相关的行为。每个具体状态类对应环境类的一个具体状态，不同的具体状态类其行为有所不同。
:::info
在状态模式的使用过程中，一个对象的状态之间还可以进行相互转换。通常有以下两种实现状态转换的方式：
:::
（1）统一由环境类来负责状态之间的转换。此时，环境类还充当了状态管理器（State Manager）角色。在环境类的业务方法中通过对某些属性值的判断实现状态转换，还可以提供一个专门的方法用于实现属性判断和状态转换。
...
public void changeState() {
if(value==0) {
this.setState(new ConcreteStateA());
}else if(){
}
...
else{
}
}
...
（2）由具体状态类来负责状态之间的转换。可以在具体状态类的业务方法中判断环境类的某些属性值再根据情况为环境类设置新的状态对象，实现状态转换。同样，也可以提供一个专门的方法来负责属性值的判断和状态转换。此时，状态类与环境类之间将存在依赖或关联关系，因为状态类需要访问环境类中的属性值。代码片段如下：
...
public void changeState(Context ctx) {
if(ctx.getValue() == 1) {
ctx.setState(new ConcreteStateA());
} else if {
...
}else {
...
}
}
...
简单实现
package behavior;
public class StateDemo {
public static void main(String[] args) {
Context context = new Context();
State stateA = new ConcreteStateA();
context.setState(stateA);
context.request();
State stateB = new ConcreteStateB();
context.setState(stateB);
context.request();
}
public static abstract class State {
abstract public void handler();
}
public static class ConcreteStateA extends State {
@Override
public void handler() {
System.out.println(">>>>>> A");
}
}
public static class ConcreteStateB extends State {
@Override
public void handler() {
System.out.println(">>>>>> B");
}
}
public static class Context {
private State state;
public void setState(State state) {
this.state = state;
}
public void request() {
state.handler();
}
}
}
总结
状态模式将一个对象在不同状态下的不同行为封装在一个个状态类中。通过设置不同的状态对象可以让环境对象拥有不同的行为，而状态转换的细节对于客户端而言是透明的，方便了客户端的使用。在实际开发中，状态模式具有较高的使用频率，在工作流、游戏等软件中状态模式都得到了广泛应用，例如公文状态的转换、游戏中角色的升级等。
主要优点
状态模式的主要优点如下：
（1）封装了状态的转换规则。在状态模式中可以将状态的转换代码封装在环境类或者具体状态类中，对状态转换代码进行集中管理，而不是分散在一个个业务方法中。
（2）将所有与某个状态有关的行为放到一个类中，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为。
（3）允许状态转换逻辑与状态对象合成一体，而不是提供一个巨大的条件语句块。状态模式可以避免使用庞大的条件语句来将业务方法和状态转换代码交织在一起。
（4）可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
主要缺点
状态模式的主要缺点如下：
（1）状态模式的使用必然会增加系统中类和对象的个数，导致系统运行开销增大。
（2）状态模式的程序结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱，增加系统设计的难度。
（3）状态模式对开闭原则的支持并不太好。增加新的状态类需要修改那些负责状态转换的源代码，否则无法转换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。
适用场景
🚀 作者简介：作为某云服务提供商的后端开发人员，我将在这里与大家简要分享一些实用的开发小技巧。在我的职业生涯中积累了丰富的经验，希望能通过这个博客与大家交流、学习和成长。技术栈：Java、Golang、PHP、Python、Vue、React
本文收录于三木的
💐 「设计模式」专栏
此外三木还有以下专栏在同步更新～
🌼 「AI」专栏
🔥「面试」这个专栏的灵感来自于许多粉丝私信，大家向我咨询有关面试的问题和建议。我深感荣幸和责任，希望通过这个专栏，能够为大家提供更多关于面试的知识、技巧和经验。我们将一起探讨面试。期待粉丝们ssp的offer喜讯。
🎈 「Java探索者之路」系列专栏，这个专栏旨在引领Java开发者踏上一段真正探索Java世界的旅程。
我们将深入探讨Java编程的方方面面，从基础知识到高级技巧，从实践案例到最新趋势，帮助你成为一名卓越的Java探索者。如果有想进入Java后端领域工作的同学，这个专栏会对你有所帮助，欢迎关注起来呀
🌊 「Python爬虫」的入门学习系列，大家有兴趣的可以看一看
🌹一起学习，互三互访，顺评论区有访必回，有关必回！！！
