Java 设计模式系列：行为型-状态模式

简介

状态模式（State Pattern）是一种行为型设计模式，允许一个对象在其内部状态改变时改变其行为。状态模式中类的行为是由状态决定的，在不同的状态下有不同的行为。

状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。

适用场景：一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为；一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态。

状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化。对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致处理。

结构

状态模式包含以下主要角色。

  1. 环境类（Context）：又称上下文类，它是拥有多种状态的对象。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个state子类的对象。
  2. 抽象状态类（IState）：定义该状态下的行为，可以有一个或多个行为。
  3. 具体状态类（ConcreteState）：实现了抽象状态类中的方法，定义了该状态下环境的操作。

案例实现

例】通过按钮来控制一个电梯的状态，一个电梯有开门状态，关门状态，停止状态，运行状态。每一种状态改变，都有可能要根据其他状态来更新处理。例如，如果电梯门现在处于运行时状态，就不能进行开门操作，而如果电梯门是停止状态，就可以执行开门操作。

类图如下：

简介

状态模式（State Pattern）是一种行为型设计模式，允许一个对象在其内部状态改变时改变其行为。状态模式中类的行为是由状态决定的，在不同的状态下有不同的行为。

状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。

适用场景：一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为；一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态。

状态模式将一个对象的状态从该对象中分离出来，封装到专门的状态类中，使得对象状态可以灵活变化。对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态，无论对于何种状态的对象，客户端都可以一致处理。

结构

状态模式包含以下主要角色。

  1. 环境类（Context）：又称上下文类，它是拥有多种状态的对象。在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个state子类的对象。
  2. 抽象状态类（IState）：定义该状态下的行为，可以有一个或多个行为。
  3. 具体状态类（ConcreteState）：实现了抽象状态类中的方法，定义了该状态下环境的操作。

案例实现

例】通过按钮来控制一个电梯的状态，一个电梯有开门状态，关门状态，停止状态，运行状态。每一种状态改变，都有可能要根据其他状态来更新处理。例如，如果电梯门现在处于运行时状态，就不能进行开门操作，而如果电梯门是停止状态，就可以执行开门操作。

类图如下：

代码如下：

public interface ILift {//电梯的4个状态//开门状态public final static int OPENING_STATE = 1;//关门状态public final static int CLOSING_STATE = 2;//运行状态public final static int RUNNING_STATE = 3;//停止状态public final static int STOPPING_STATE = 4;//设置电梯的状态public void setState(int state);//电梯的动作public void open();public void close();public void run();public void stop();
}public class Lift implements ILift {private int state;@Overridepublic void setState(int state) {this.state = state;}//执行关门动作@Overridepublic void close() {switch (this.state) {case OPENING_STATE:System.out.println("电梯关门了。。。");//只有开门状态可以关闭电梯门，可以对应电梯状态表来看this.setState(CLOSING_STATE);//关门之后电梯就是关闭状态了break;case CLOSING_STATE://do nothing //已经是关门状态，不能关门break;case RUNNING_STATE://do nothing //运行时电梯门是关着的，不能关门break;case STOPPING_STATE://do nothing //停止时电梯也是关着的，不能关门break;}}//执行开门动作@Overridepublic void open() {switch (this.state) {case OPENING_STATE://门已经开了，不能再开门了//do nothingbreak;case CLOSING_STATE://关门状态，门打开:System.out.println("电梯门打开了。。。");this.setState(OPENING_STATE);break;case RUNNING_STATE://do nothing 运行时电梯不能开门break;case STOPPING_STATE:System.out.println("电梯门开了。。。");//电梯停了，可以开门了this.setState(OPENING_STATE);break;}}//执行运行动作@Overridepublic void run() {switch (this.state) {case OPENING_STATE://电梯不能开着门就走//do nothingbreak;case CLOSING_STATE://门关了，可以运行了System.out.println("电梯开始运行了。。。");this.setState(RUNNING_STATE);//现在是运行状态break;case RUNNING_STATE://do nothing 已经是运行状态了break;case STOPPING_STATE:System.out.println("电梯开始运行了。。。");this.setState(RUNNING_STATE);break;}}//执行停止动作@Overridepublic void stop() {switch (this.state) {case OPENING_STATE: //开门的电梯已经是是停止的了(正常情况下)//do nothingbreak;case CLOSING_STATE://关门时才可以停止System.out.println("电梯停止了。。。");this.setState(STOPPING_STATE);break;case RUNNING_STATE://运行时当然可以停止了System.out.println("电梯停止了。。。");this.setState(STOPPING_STATE);break;case STOPPING_STATE://do nothingbreak;}}
}public class Client {public static void main(String[] args) {Lift lift = new Lift();lift.setState(ILift.STOPPING_STATE);//电梯是停止的lift.open();//开门lift.close();//关门lift.run();//运行lift.stop();//停止}
}

问题分析：

  • 使用了大量的switch…case这样的判断（if…else也是一样)，使程序的可阅读性变差。
  • 扩展性很差。如果新加了断电的状态，我们需要修改上面判断逻辑

改进

对上述电梯的案例使用状态模式进行改进。类图如下：

代码如下：

//抽象状态类
public abstract class LiftState {//定义一个环境角色，也就是封装状态的变化引起的功能变化protected Context context;public void setContext(Context context) {this.context = context;}//电梯开门动作public abstract void open();//电梯关门动作public abstract void close();//电梯运行动作public abstract void run();//电梯停止动作public abstract void stop();
}//开启状态
public class OpenningState extends LiftState {//开启当然可以关闭了，我就想测试一下电梯门开关功能@Overridepublic void open() {System.out.println("电梯门开启...");}@Overridepublic void close() {//状态修改super.context.setLiftState(Context.closeingState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().close();}//电梯门不能开着就跑，这里什么也不做@Overridepublic void run() {//do nothing}//开门状态已经是停止的了@Overridepublic void stop() {//do nothing}
}//运行状态
public class RunningState extends LiftState {//运行的时候开电梯门？你疯了！电梯不会给你开的@Overridepublic void open() {//do nothing}//电梯门关闭？这是肯定了@Overridepublic void close() {//虽然可以关门，但这个动作不归我执行//do nothing}//这是在运行状态下要实现的方法@Overridepublic void run() {System.out.println("电梯正在运行...");}//这个事绝对是合理的，光运行不停止还有谁敢做这个电梯？！估计只有上帝了@Overridepublic void stop() {super.context.setLiftState(Context.stoppingState);super.context.stop();}
}//停止状态
public class StoppingState extends LiftState {//停止状态，开门，那是要的！@Overridepublic void open() {//状态修改super.context.setLiftState(Context.openningState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().open();}@Overridepublic void close() {//虽然可以关门，但这个动作不归我执行//状态修改super.context.setLiftState(Context.closeingState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().close();}//停止状态再跑起来，正常的很@Overridepublic void run() {//状态修改super.context.setLiftState(Context.runningState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().run();}//停止状态是怎么发生的呢？当然是停止方法执行了@Overridepublic void stop() {System.out.println("电梯停止了...");}
}//关闭状态
public class ClosingState extends LiftState {@Override//电梯门关闭，这是关闭状态要实现的动作public void close() {System.out.println("电梯门关闭...");}//电梯门关了再打开，逗你玩呢，那这个允许呀@Overridepublic void open() {super.context.setLiftState(Context.openningState);super.context.open();}//电梯门关了就跑，这是再正常不过了@Overridepublic void run() {super.context.setLiftState(Context.runningState);super.context.run();}//电梯门关着，我就不按楼层@Overridepublic void stop() {super.context.setLiftState(Context.stoppingState);super.context.stop();}
}//环境角色
public class Context {//定义出所有的电梯状态public final static OpenningState openningState = new OpenningState();//开门状态，这时候电梯只能关闭public final static ClosingState closeingState = new ClosingState();//关闭状态，这时候电梯可以运行、停止和开门public final static RunningState runningState = new RunningState();//运行状态，这时候电梯只能停止public final static StoppingState stoppingState = new StoppingState();//停止状态，这时候电梯可以开门、运行//定义一个当前电梯状态private LiftState liftState;public LiftState getLiftState() {return this.liftState;}public void setLiftState(LiftState liftState) {//当前环境改变this.liftState = liftState;//把当前的环境通知到各个实现类中this.liftState.setContext(this);}public void open() {this.liftState.open();}public void close() {this.liftState.close();}public void run() {this.liftState.run();}public void stop() {this.liftState.stop();}
}//测试类
public class Client {public static void main(String[] args) {Context context = new Context();context.setLiftState(new ClosingState());context.open();context.close();context.run();context.stop();}
}

优缺点

1，优点：

  • 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
  • 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。

2，缺点：

  • 状态模式的使用必然会增加系统类和对象的个数。
  • 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
  • 状态模式对"开闭原则"的支持并不太好。

使用场景

  • 当一个对象的行为取决于它的状态，并且它必须在运行时根据状态改变它的行为时，就可以考虑使用状态模式。
  • 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态时。

代码如下：

public interface ILift {//电梯的4个状态//开门状态public final static int OPENING_STATE = 1;//关门状态public final static int CLOSING_STATE = 2;//运行状态public final static int RUNNING_STATE = 3;//停止状态public final static int STOPPING_STATE = 4;//设置电梯的状态public void setState(int state);//电梯的动作public void open();public void close();public void run();public void stop();
}public class Lift implements ILift {private int state;@Overridepublic void setState(int state) {this.state = state;}//执行关门动作@Overridepublic void close() {switch (this.state) {case OPENING_STATE:System.out.println("电梯关门了。。。");//只有开门状态可以关闭电梯门，可以对应电梯状态表来看this.setState(CLOSING_STATE);//关门之后电梯就是关闭状态了break;case CLOSING_STATE://do nothing //已经是关门状态，不能关门break;case RUNNING_STATE://do nothing //运行时电梯门是关着的，不能关门break;case STOPPING_STATE://do nothing //停止时电梯也是关着的，不能关门break;}}//执行开门动作@Overridepublic void open() {switch (this.state) {case OPENING_STATE://门已经开了，不能再开门了//do nothingbreak;case CLOSING_STATE://关门状态，门打开:System.out.println("电梯门打开了。。。");this.setState(OPENING_STATE);break;case RUNNING_STATE://do nothing 运行时电梯不能开门break;case STOPPING_STATE:System.out.println("电梯门开了。。。");//电梯停了，可以开门了this.setState(OPENING_STATE);break;}}//执行运行动作@Overridepublic void run() {switch (this.state) {case OPENING_STATE://电梯不能开着门就走//do nothingbreak;case CLOSING_STATE://门关了，可以运行了System.out.println("电梯开始运行了。。。");this.setState(RUNNING_STATE);//现在是运行状态break;case RUNNING_STATE://do nothing 已经是运行状态了break;case STOPPING_STATE:System.out.println("电梯开始运行了。。。");this.setState(RUNNING_STATE);break;}}//执行停止动作@Overridepublic void stop() {switch (this.state) {case OPENING_STATE: //开门的电梯已经是是停止的了(正常情况下)//do nothingbreak;case CLOSING_STATE://关门时才可以停止System.out.println("电梯停止了。。。");this.setState(STOPPING_STATE);break;case RUNNING_STATE://运行时当然可以停止了System.out.println("电梯停止了。。。");this.setState(STOPPING_STATE);break;case STOPPING_STATE://do nothingbreak;}}
}public class Client {public static void main(String[] args) {Lift lift = new Lift();lift.setState(ILift.STOPPING_STATE);//电梯是停止的lift.open();//开门lift.close();//关门lift.run();//运行lift.stop();//停止}
}

问题分析：

  • 使用了大量的switch…case这样的判断（if…else也是一样)，使程序的可阅读性变差。
  • 扩展性很差。如果新加了断电的状态，我们需要修改上面判断逻辑

改进

对上述电梯的案例使用状态模式进行改进。类图如下：

代码如下：

//抽象状态类
public abstract class LiftState {//定义一个环境角色，也就是封装状态的变化引起的功能变化protected Context context;public void setContext(Context context) {this.context = context;}//电梯开门动作public abstract void open();//电梯关门动作public abstract void close();//电梯运行动作public abstract void run();//电梯停止动作public abstract void stop();
}//开启状态
public class OpenningState extends LiftState {//开启当然可以关闭了，我就想测试一下电梯门开关功能@Overridepublic void open() {System.out.println("电梯门开启...");}@Overridepublic void close() {//状态修改super.context.setLiftState(Context.closeingState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().close();}//电梯门不能开着就跑，这里什么也不做@Overridepublic void run() {//do nothing}//开门状态已经是停止的了@Overridepublic void stop() {//do nothing}
}//运行状态
public class RunningState extends LiftState {//运行的时候开电梯门？你疯了！电梯不会给你开的@Overridepublic void open() {//do nothing}//电梯门关闭？这是肯定了@Overridepublic void close() {//虽然可以关门，但这个动作不归我执行//do nothing}//这是在运行状态下要实现的方法@Overridepublic void run() {System.out.println("电梯正在运行...");}//这个事绝对是合理的，光运行不停止还有谁敢做这个电梯？！估计只有上帝了@Overridepublic void stop() {super.context.setLiftState(Context.stoppingState);super.context.stop();}
}//停止状态
public class StoppingState extends LiftState {//停止状态，开门，那是要的！@Overridepublic void open() {//状态修改super.context.setLiftState(Context.openningState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().open();}@Overridepublic void close() {//虽然可以关门，但这个动作不归我执行//状态修改super.context.setLiftState(Context.closeingState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().close();}//停止状态再跑起来，正常的很@Overridepublic void run() {//状态修改super.context.setLiftState(Context.runningState);//动作委托为CloseState来执行，也就是委托给了ClosingState子类执行这个动作super.context.getLiftState().run();}//停止状态是怎么发生的呢？当然是停止方法执行了@Overridepublic void stop() {System.out.println("电梯停止了...");}
}//关闭状态
public class ClosingState extends LiftState {@Override//电梯门关闭，这是关闭状态要实现的动作public void close() {System.out.println("电梯门关闭...");}//电梯门关了再打开，逗你玩呢，那这个允许呀@Overridepublic void open() {super.context.setLiftState(Context.openningState);super.context.open();}//电梯门关了就跑，这是再正常不过了@Overridepublic void run() {super.context.setLiftState(Context.runningState);super.context.run();}//电梯门关着，我就不按楼层@Overridepublic void stop() {super.context.setLiftState(Context.stoppingState);super.context.stop();}
}//环境角色
public class Context {//定义出所有的电梯状态public final static OpenningState openningState = new OpenningState();//开门状态，这时候电梯只能关闭public final static ClosingState closeingState = new ClosingState();//关闭状态，这时候电梯可以运行、停止和开门public final static RunningState runningState = new RunningState();//运行状态，这时候电梯只能停止public final static StoppingState stoppingState = new StoppingState();//停止状态，这时候电梯可以开门、运行//定义一个当前电梯状态private LiftState liftState;public LiftState getLiftState() {return this.liftState;}public void setLiftState(LiftState liftState) {//当前环境改变this.liftState = liftState;//把当前的环境通知到各个实现类中this.liftState.setContext(this);}public void open() {this.liftState.open();}public void close() {this.liftState.close();}public void run() {this.liftState.run();}public void stop() {this.liftState.stop();}
}//测试类
public class Client {public static void main(String[] args) {Context context = new Context();context.setLiftState(new ClosingState());context.open();context.close();context.run();context.stop();}
}

优缺点

1，优点：

  • 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
  • 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。

2，缺点：

  • 状态模式的使用必然会增加系统类和对象的个数。
  • 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
  • 状态模式对"开闭原则"的支持并不太好。

使用场景

  • 当一个对象的行为取决于它的状态，并且它必须在运行时根据状态改变它的行为时，就可以考虑使用状态模式。
  • 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态时。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/756818.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

[Labtools 27-1429] XML parser encountered a problem in file

[Labtools 27-1429] XML parser encountered a problem in file

平台：Vivado2108.3 最近在使用vivado的debug过程中发现，编译好工程后打开open hardware manager出现如下错误。 [Labtools 27-1429] XML parser encountered a problem in file E:/githome/xxxx/hw_1/hw.xml at line 1 : XML character encoding not su…
阅读更多...
智能合约语言（eDSL）—— 使用rust实现eDSL的原理

智能合约语言（eDSL）—— 使用rust实现eDSL的原理

为理解rust变成eDSL的实现原理，我们需要简单了解元编程与宏的概念,元编程被描述成一种计算机程序可以将代码看待成数据的能力，使用元编程技术编写的程序能够像普通程序在运行时更新、替换变量那样操作更新、替换代码。宏在 Rust 语言中是一种功能&#x…
阅读更多...
机器人离散化阻抗控制

机器人离散化阻抗控制

机器人离散化阻抗控制是一种控制策略，它结合了阻抗控制的思想与离散化方法，以实现对机器人运动与外力之间动态关系的精细调节。这种控制方法旨在使机器人在与环境交互时能够表现出期望的阻抗特性，从而实现对接触力和位置的精确控制。 在离散…
阅读更多...
STM32—控制蜂鸣器（定时器）

STM32—控制蜂鸣器（定时器）

目录 1 、 电路构成及原理图 2 、编写实现代码 main.c tim_irq.c 3、代码讲解 4、烧录到开发板调试、验证代码 5、检验效果 此笔记基于朗峰 STM32F103 系列全集成开发板的记录。 1 、 电路构成及原理图 定时器中断是利用定时器的计数功能（向上计数或向下计…
阅读更多...
算法---二分查找练习-3（山脉数组的顶峰索引）

算法---二分查找练习-3（山脉数组的顶峰索引）

山脉数组的顶峰索引 1. 题目解析2. 讲解算法原理3. 编写代码 1. 题目解析 题目地址&#xff1a;点这里 2. 讲解算法原理 初始化两个指针 left 和 right&#xff0c;分别指向数组的起始位置和结束位置。 进入循环&#xff0c;循环条件为 left < right。 在每次循环中&…
阅读更多...
Visual Studio - 添加快捷键图标

Visual Studio - 添加快捷键图标

Visual Studio - 添加快捷键图标 1. Text Editor Toolbar Options -> Add or Remove Buttons -> Customize2. Toolbars3. Commands -> Debug4. Add Command...References 1. Text Editor Toolbar Options -> Add or Remove Buttons -> Customize 2. Toolbars B…
阅读更多...
机器学习-05-特征工程

机器学习-05-特征工程

总结 本系列是机器学习课程的系列课程&#xff0c;主要介绍机器学习中特征工程部分。 参考 机器学习之特征工程详解 特征工程&#xff08;Feature Engineering&#xff09; 特征工程是指使用专业的背景知识和技巧处理数据&#xff0c;使得特征能在机器学习算法上发生更好的…
阅读更多...
Lvs+keepalived+nginx搭建高可用负载均衡集群

Lvs+keepalived+nginx搭建高可用负载均衡集群

环境配置 master主机192.168.199.149&#xff0c;虚拟IP192.168.199.148 back备机192.168.199.150 真实服务器1 192.168.199.155 真实服务器2 192.168.199.156 关闭防火墙和selinux master配置&#xff08;149&#xff09; 添加虚拟IP ip addr add 192.168.199.148/24 …
阅读更多...
手机备忘录隐藏功能：生日纪念日重要日子倒计时天数和提醒

手机备忘录隐藏功能：生日纪念日重要日子倒计时天数和提醒

在日常使用手机时&#xff0c;我们经常会用到备忘录、便签或笔记等记事工具来记录生活的点点滴滴&#xff0c;无论是购物清单、工作任务还是学习笔记。然而&#xff0c;你可能不知道&#xff0c;手机备忘录中其实隐藏着一些非常实用的功能&#xff0c;比如记录生日、纪念日、重…
阅读更多...
Java设计模式 | 简单工厂模式

Java设计模式 | 简单工厂模式

概述 需求 设计一个咖啡店点餐系统设计一个咖啡类&#xff08;Coffee&#xff09;&#xff1b;并定义其两个子类&#xff08;美式咖啡AmericanCoffee和拿铁咖啡LatteCoffee&#xff09;&#xff1b;再设计一个咖啡店类&#xff08;CoffeeStore&#xff09;&#xff0c;其具备…
阅读更多...
Node.js常用命令：了解Node.js的核心命令和用法

Node.js常用命令：了解Node.js的核心命令和用法

学习目标&#xff1a; 理解Node.js和npm的概念及其在开发中的作用&#xff1b;掌握Node.js的核心命令&#xff0c;包括node、npm、npx等&#xff1b;学会使用node命令来执行JavaScript文件和模块&#xff1b;熟悉npm命令&#xff0c;包括安装、更新、卸载依赖包等操作&#xf…
阅读更多...
【Ubuntu】常用命令

【Ubuntu】常用命令

一般操作 pwd&#xff08;present working directory&#xff09; 显示当前的工作目录/路径。 cd (change directory) 改变目录&#xff0c;用于输入需要前往的路径/目录。 有一些特殊命令也很常用 : 解释 前往同一级的另一个目录 cd ../directory name cd .. 表示进入上…
阅读更多...
STP环路避免实验（华为）

STP环路避免实验（华为）

思科设备参考&#xff1a;STP环路避免实验&#xff08;思科&#xff09; 一&#xff0c;技术简介 Spanning Tree Protocol&#xff08;STP&#xff09;&#xff0c;即生成树协议&#xff0c;是一种数据链路层协议。主要作用是防止二层环路&#xff0c;并自适应网络变化和故障…
阅读更多...
unity学习（62）——emptyObject+昵称+血条

unity学习（62）——emptyObject+昵称+血条

1.地图比较麻烦&#xff0c;先最后回头再做&#xff0c;地图是锦上添花的东西。 2.MapHandler中的使用技巧&#xff1a; 2.1.继承必须有&#xff0c;要不脚本绑不到相机上 2.2当场景被调用时触发函数OnLevelWasLoaded&#xff0c;这个和Start一样属于一个机制函数。 3.自己做…
阅读更多...
长安链Docker Java智能合约引擎的架构、应用与规划

长安链Docker Java智能合约引擎的架构、应用与规划

#功能发布 长安链3.0正式版发布了多个重点功能&#xff0c;包括共识算法切换、支持java智能合约引擎、支持后量子密码、web3生态兼容等。我们接下来为大家详细介绍新功能的设计、应用与规划。 在《2022年度长安链开源社区开发者调研报告》中&#xff0c;对Java合约语言支持是开…
阅读更多...
51单片机—直流电机

51单片机—直流电机

1.元件介绍 2.驱动电路 3.电机调速 一般会保证一个周期的时间是一样的 应用&#xff1a; 1.LED呼吸灯 #include <REGX52.H>sbit LEDP2^0;void Delay(unsigned int t) {while(t--); } void main() {unsigned char Time,i;while(1){for(Time0;Time<100;Time){for(i0;…
阅读更多...
【前端寻宝之路】学习和总结HTML的标签属性

【前端寻宝之路】学习和总结HTML的标签属性

&#x1f308;个人主页: Aileen_0v0 &#x1f525;热门专栏: 华为鸿蒙系统学习|计算机网络|数据结构与算法|MySQL| ​&#x1f4ab;个人格言:“没有罗马,那就自己创造罗马~” 前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&#xff0c;风趣幽默&#xff0c;忍不…
阅读更多...
Linux-Arm环境下配置编译qt-everywhere及交叉编译环境

Linux-Arm环境下配置编译qt-everywhere及交叉编译环境

前言 最近在搞交叉编译的事&#xff0c;手上拿了个同事的香橙派玩交叉编译&#xff0c;现在来到了第一步&#xff0c;就是先在arm上配置qt的开发环境。当然了Qt没有直接提供qt on arm&#xff0c;而是需要自行在arm环境下编译一个qt环境出来&#xff0c;所以这里需要使用到qt提…
阅读更多...
【Linux】vim详细介绍（四）

【Linux】vim详细介绍（四）

文章目录 什么是 vimvim的主要功能&#xff1a;vim的三种模式.viminfo和.vimrc文件 什么是 vim 点击跳转至官网了解更多 Vim是一款功能强大的文本编辑器&#xff0c;适用于各种编程和文本处理任务&#xff0c;最初由Bram Moolenaar开发于1991年。它是Vi编辑器的增强版&#xf…
阅读更多...
GitHub Copilot+ESP开发实战-串口

GitHub Copilot+ESP开发实战-串口

上篇文章讲了GitHub Copilot在应用中可能遇到的问题&#xff0c;接下来小启就简单介绍下GitHub Copilot在ESP32开发中C语言实现串口功能&#xff0c;感兴趣的可以看看。 一、向Copilot提问&#xff1a; 1. ESP32用C语言实现串口初始化&#xff1b; 2.配置uart为1&#xff0c…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023