探索设计模式的魅力:状态模式揭秘-如何优雅地处理复杂状态转换

在这里插入图片描述
​🌈 个人主页:danci_
🔥 系列专栏:《设计模式》
💪🏻 制定明确可量化的目标,并且坚持默默的做事。


探索设计模式的魅力:状态模式揭秘-如何优雅地处理复杂状态转换

文章目录

  • 一、案例场景🔍
    • 1.1 经典的运用场景
    • 1.2 一坨坨代码实现😻
    • 1.3 痛点
  • 二、解决方案
    • 2.1 定义
    • 2.2 案例分析🧐
    • 2.3 状态模式结构图及说明
    • 2.4 使用状态模式重构示例
    • 2.5 重构后解决的问题
  • 三、模式讲解
    • 3.1 认识状态模式
    • 3.2 实现方式
    • 3.3 思考状态模式
  • 四、总结
    • 4.1 优点
    • 4.2 缺点
    • 3.3 挑战和限制

一、案例场景🔍

1.1 经典的运用场景

    状态模式是一种行为设计模式,它允许对象在其内部状态改变时改变它的行为。这个模式使得对象看起来好像修改了它的类。以下是几个状态模式的经典场景:

  • ✨订单处理系统: 在电商系统中,订单的状态可能会经历多个阶段,如“待支付”、“已支付”、“待发货”、“已发货”、“已完成”等。每个状态对应不同的行为,比如“待支付”状态下可以进行支付操作,“已发货”状态下可以查询物流信息等。通过状态模式,我们可以清晰地管理订单的状态转换和相关行为。
  • ✨交通信号灯控制系统: 交通信号灯有红、黄、绿三种状态,每种状态下信号灯的行为是不同的。比如红灯亮时,车辆需要停止;绿灯亮时,车辆可以通行;黄灯亮时,车辆需要准备停止。通过状态模式,我们可以方便地实现信号灯的状态转换和控制逻辑。
  • ✨用户登录状态管理: 在用户登录系统中,用户的状态可以分为“未登录”、“已登录”等。不同状态下,用户的权限和操作是不同的。比如未登录状态下,用户只能浏览部分页面;已登录状态下,用户可以访问更多功能和页面。通过状态模式,我们可以实现用户登录状态的管理和权限控制。

    下面我们来实现✨订单处理系统。

1.2 一坨坨代码实现😻

在这里插入图片描述

    使用一个简单的状态机和状态枚举来实现这个场景。下面是一个基于Java的简单实现示例:

  1. 首先,定义一个表示订单状态的枚举:
public enum OrderStatus {  PENDING_PAYMENT("待支付"),  PAYMENT_RECEIVED("已支付"),  SHIPPED("已发货"),  COMPLETED("已完成");  private final String displayName;  OrderStatus(String displayName) {  this.displayName = displayName;  }  public String getDisplayName() {  return displayName;  }  // 可以根据需要添加更多方法,比如判断是否可以转换到某个状态等  
}
  1. 接下来,我们定义一个Order类来表示订单及其状态转换的逻辑:
public class Order {  private OrderStatus status;  private String orderId;  public Order(String orderId) {  this.orderId = orderId;  this.status = OrderStatus.PENDING_PAYMENT; // 初始状态为待支付  }  public String getOrderId() {  return orderId;  }  public OrderStatus getStatus() {  return status;  }  // 状态转换方法  public void pay() {  if (status == OrderStatus.PENDING_PAYMENT) {  status = OrderStatus.PAYMENT_RECEIVED;  System.out.println("Order " + orderId + " status changed to: " + status.getDisplayName());  } else {  System.out.println("Cannot pay for order " + orderId + " in its current state.");  }  }  public void ship() {  if (status == OrderStatus.PAYMENT_RECEIVED) {  status = OrderStatus.SHIPPED;  System.out.println("Order " + orderId + " status changed to: " + status.getDisplayName());  } else {  System.out.println("Cannot ship order " + orderId + " in its current state.");  }  }  public void complete() {  if (status == OrderStatus.SHIPPED) {  status = OrderStatus.COMPLETED;  System.out.println("Order " + orderId + " status changed to: " + status.getDisplayName());  } else {  System.out.println("Cannot complete order " + orderId + " in its current state.");  }  }  // 可以根据需要添加更多方法和逻辑  
}
  1. 现在,你可以通过创建一个Order对象并调用其状态转换方法来模拟订单的状态变化:
public class OrderProcessingDemo {  public static void main(String[] args) {  Order order = new Order("12345");  System.out.println("Current order status: " + order.getStatus().getDisplayName());  order.pay();  System.out.println("Current order status: " + order.getStatus().getDisplayName());  order.ship();  System.out.println("Current order status: " + order.getStatus().getDisplayName());  order.complete();  System.out.println("Current order status: " + order.getStatus().getDisplayName());  // 尝试在非法状态下进行状态转换  order.pay(); // 应该不会成功,因为订单已经完成  }  
}

    在这个实现中,我们直接在Order类中处理了状态转换的逻辑。每个状态转换方法(pay、ship、complete)都会检查当前状态是否允许进行转换,并相应地更新状态或打印错误消息。虽然这个实现很简单,但它缺乏一些设计模式所提供的灵活性和可扩展性。在实际项目中,你可能会考虑使用状态模式、策略模式或模板方法模式等来实现更复杂的状态管理逻辑。然而,根据题目的要求,这里提供了一个不使用设计模式的简单实现。

1.3 痛点

在这里插入图片描述
    上述实现确实存在一些缺点,下面逐一分析:

  1. 硬编码的状态转换逻辑:
    在上述实现中,状态转换的逻辑是直接硬编码在Order类中的pay、ship和complete方法里。这意味着如果未来需要添加新的状态或更改现有的状态转换逻辑,我们必须修改Order类的源代码。这违反了开闭原则(Open-Closed Principle),即软件实体应该对扩展开放,对修改关闭。
  2. 缺乏灵活性:
    由于状态转换逻辑是固定的,系统无法轻松适应新的业务规则或变化。例如,如果引入了一个新的状态“部分发货”,或者某些状态下允许退款操作,现有的代码结构将难以应对这些变化。
  3. 状态和行为紧密耦合:
    在上述实现中,状态和与状态相关的行为(即状态转换)是紧密耦合的。这导致了高内聚低耦合的设计原则的违反。理想情况下,状态应该只表示数据,而行为应该由独立的组件(如状态机)来管理。
  4. 可维护性问题:
    随着业务逻辑的增长和复杂性的增加,直接在Order类中管理状态转换将变得越来越困难。代码将变得难以理解和维护,特别是当多个开发人员参与项目时。
  5. 错误处理不足:
    在当前实现中,错误处理仅限于打印错误消息到控制台。在实际的生产环境中,通常需要更复杂的错误处理机制,如回滚操作、日志记录、通知用户或管理员等。
  6. 可扩展性问题:
    由于状态转换逻辑直接嵌入在Order类中,因此添加新的状态或转换逻辑需要修改现有的类结构。这可能会引入新的错误并破坏现有功能的稳定性。此外,每次添加新功能时都需要重新测试和验证整个系统。

二、解决方案

在这里插入图片描述
    使用状态模式可以有效地解决上述提到的一些缺点。状态模式允许一个对象在其内部状态改变时改变它的行为,使得对象看起来好像修改了它的类。在状态模式中,我们定义状态和状态之间的转换,将状态转换的逻辑封装在状态对象自身中,而不是将其分散在多个条件语句中。

2.1 定义

状态模式(State Pattern)是一种行为设计模式,它允许一个对象在其内部状态改变时改变它的行为。状态模式把与特定状态相关的行为封装到一个个的类中,当对象的状态改变时,它的行为也会随着改变。

2.2 案例分析🧐

在这里插入图片描述

2.3 状态模式结构图及说明

在这里插入图片描述
主要组件:

  1. Context(上下文):它定义了客户感兴趣的接口,并且维护一个具体状态对象的实例,这个具体状态对象定义了当前状态。
  2. State(抽象状态):这是一个抽象类,它定义了状态转换的接口,这个接口由具体状态类实现。
  3. ConcreteState(具体状态):具体状态类实现了抽象状态定义的接口,从而实现状态转换和具体行为。

说明:

  1. 封装了状态的转换逻辑:状态模式将状态转换逻辑封装在状态类中,而不是散布在多个条件语句中。这有助于减少代码的复杂性,并使状态转换逻辑更易于理解和维护。
  2. 增加新的状态或行为变得更容易:由于状态和行为都被封装在单独的类中,因此添加新的状态或行为只需要添加新的状态类,而不需要修改其他代码。这符合开闭原则,即对扩展开放,对修改封闭。
  3. 状态转换的显式化:状态模式使得状态转换变得显式化,因为状态的转换是通过调用状态对象的方法来实现的,而不是通过修改上下文的状态变量来实现的。这使得状态转换更加清晰和可预测。
  4. 过多的状态类可能导致类爆炸:如果一个对象有很多状态,并且每个状态的行为差异很大,那么可能需要为每个状态创建一个单独的类。这可能会导致类数量过多,增加系统的复杂性。

2.4 使用状态模式重构示例

    使用状态模式来实现上述场景时,首先需要定义状态接口和具体的状态类,然后在上下文类(如Order)中维护一个对当前状态的引用。状态类将封装与特定状态相关的行为,包括状态转换。
    下面是一个使用状态模式实现的订单处理系统的示例:

  1. 状态接口
public interface OrderState {  void pay(Order order);  void ship(Order order);  void complete(Order order);  // 可能还需要其他方法,如退款、部分发货等  
} 
  1. 具体的状态类
public class CreatedState implements OrderState {  @Override  public void pay(Order order) {  // 处理支付逻辑  System.out.println("Order paid.");  order.setState(new PaidState());  }  @Override  public void ship(Order order) {  System.out.println("Cannot ship order in Created state.");  }  @Override  public void complete(Order order) {  System.out.println("Cannot complete order in Created state.");  }  
}
public class PaidState implements OrderState {  @Override  public void pay(Order order) {  System.out.println("Order already paid.");  }  @Override  public void ship(Order order) {  // 处理发货逻辑  System.out.println("Order shipped.");  order.setState(new ShippedState());  }  @Override  public void complete(Order order) {  System.out.println("Cannot complete order before it is shipped.");  }  
}  public class ShippedState implements OrderState {  @Override  public void pay(Order order) {  System.out.println("Order already paid and shipped.");  }  @Override  public void ship(Order order) {  System.out.println("Order already shipped.");  }  @Override  public void complete(Order order) {  // 处理完成订单逻辑  System.out.println("Order completed.");  order.setState(new CompletedState());  }  
}  public class CompletedState implements OrderState {  @Override  public void pay(Order order) {  System.out.println("Cannot pay for a completed order.");  }  @Override  public void ship(Order order) {  System.out.println("Cannot ship a completed order.");  }  @Override  public void complete(Order order) {  System.out.println("Order already completed.");  }  
}  
  1. 上下文类
public class Order {  private OrderState state;  public Order() {  this.state = new CreatedState(); // 初始状态  }  public void setState(OrderState state) {  this.state = state;  }  public void pay() {  state.pay(this);  }  public void ship() {  state.ship(this);  }  public void complete() {  state.complete(this);  }  // 可能还有其他与订单相关的方法和属性  
}  
  1. 使用示例
public class StatePatternDemo {  public static void main(String[] args) {  Order order = new Order();  order.pay(); // 当前状态为CreatedState,调用pay会转移到PaidState  order.ship(); // 当前状态为PaidState,调用ship会转移到ShippedState  order.complete(); // 当前状态为ShippedState,调用complete会转移到CompletedState  order.pay(); // 当前状态为CompletedState,不能再支付  order.ship(); // 当前状态为CompletedState,不能再发货  order.complete(); // 当前状态为CompletedState,订单已完成  }  
}

    在这个示例中,Order类代表上下文,它有一个state字段来保存当前状态,并且提供了pay、ship和complete等方法来触发状态转换。每个具体的状态类(如CreatedState、PaidState等)都实现了OrderState接口,并定义了在当前状态下这些方法的行为。
    注:这只是一个简单的示例,实际应用中可能还需要处理更多的状态和行为,并且状态转换的逻辑可能会更加复杂。此外,为了提高代码的可维护性和可读性,还可以考虑使用枚举类型来定义状态,或者使用状态机框架来管理状态转换。

2.5 重构后解决的问题

在这里插入图片描述
    使用状态模式可以有效地解决 1.3 痛点 中提到的一些缺点。状态模式允许一个对象在其内部状态改变时改变它的行为,使得对象看起来好像修改了它的类。在状态模式中,我们定义状态和状态之间的转换,将状态转换的逻辑封装在状态对象自身中,而不是将其分散在多个条件语句中。
    以下是状态模式如何解决上述缺点的原因:

  1. 解耦状态和行为:
    在状态模式中,状态和行为被封装在单独的状态类中。这意味着Order类不再需要直接处理状态转换的逻辑。每个状态类负责定义在当前状态下允许的行为以及状态转换的规则。这大大减少了Order类的复杂性,并且使得状态和行为之间的关系更加清晰和易于管理。
  2. 提高灵活性和可扩展性:
    由于状态转换逻辑被封装在状态类中,添加新的状态或更改现有状态的行为变得相对容易。我们只需要定义新的状态类并实现相应的行为即可,而不需要修改使用状态模式的上下文类(在本例中是Order类)。这符合开闭原则,即软件实体应该对扩展开放,对修改关闭。
  3. 更好的错误处理:
    在状态模式中,状态类可以定义自己的错误处理逻辑。例如,如果尝试在不合适的状态下执行某个操作,状态类可以抛出异常或返回错误码,而不是在上下文类中打印错误消息。这提供了更好的错误处理机制,并使得错误处理更加集中和一致。
  4. 提高可维护性:
    将状态和行为封装在单独的状态类中使得代码更加模块化和可维护。每个状态类只关注自己的行为和转换规则,这使得代码更加清晰、易于理解和测试。此外,由于状态类之间是松耦合的,因此可以独立地修改和测试它们,而不会影响到其他状态类或使用它们的上下文类。
  5. 支持复杂的业务逻辑:
    状态模式能够轻松地支持复杂的业务逻辑和状态转换规则。通过定义更多的状态类和转换逻辑,我们可以实现更加精细和灵活的状态管理。此外,状态模式还可以与其他设计模式(如策略模式、观察者模式等)结合使用,以构建更加复杂和强大的软件系统。

    通过使用状态模式可以解决硬编码的状态转换逻辑、缺乏灵活性、状态和行为紧密耦合、可维护性问题以及错误处理不足等缺点。通过将状态和行为封装在单独的状态类中,我们实现了状态与行为的解耦,提高了系统的灵活性、可扩展性和可维护性。

三、模式讲解

在这里插入图片描述
  核心思想

状态模式的核心思想:将状态和行为分开。

    在这种模式下,你可以创建一个表示各种状态的对象(称为状态对象),并让这些对象负责处理在该状态下对象的行为。你的主体对象(通常称为上下文对象)将保存一个对当前状态的引用,并在其状态改变时更新这个引用。

3.1 认识状态模式

  1. 状态
    “状态”指的是对象在其生命周期内可以存在的不同状况或条件。每个状态都封装了与该状态相关的行为。
  2. 行为
    “行为”是在特定状态下对象所执行的操作或响应。每个状态都有一组与之关联的行为,这些行为在对象进入该状态时变得可用。
  3. 状态与行为的相互作用
    在状态模式中,状态和行为紧密相关。对象的行为取决于其当前状态,当状态改变时,对象的行为也会随之改变。状态转换通常由事件触发,这些事件可以是用户操作、系统事件或其他外部输入。

    状态模式通常包含一个上下文(Context)对象,它维护了对当前状态的引用,并根据当前状态来执行相应的行为。当上下文的状态改变时,它会更新其内部状态对象的引用,从而改变其行为。

3.2 实现方式

实现状态模式通常需要以下步骤:

  1. 定义状态接口或基类:这个接口或基类定义了所有可能的状态需要实现的公共接口。
  2. 实现具体的状态类:每个具体的状态类都实现了状态接口或基类,并定义了在该状态下对象的行为。
  3. 定义上下文类:这个类通常持有一个对当前状态的引用,并定义了改变状态的方法。在上下文类的方法中,你可以根据当前状态调用对应状态类的方法。

3.3 思考状态模式

  状态模式的本质

状态模式的本质:根据状态来分离和选择行为

  何时使用状态模式
    状态模式在软件开发中非常有用,特别是当对象的行为需要根据其内部状态的变化而变化时。以下情况可以考虑使用状态模式:

  1. 行为随状态改变:当一个对象的行为取决于它的状态时,并且它必须在运行时根据状态改变它的行为,状态模式就派上了用场。
  2. 消除条件语句:当一个操作中含有庞大的多分支条件语句,并且这些条件依赖于对象的状态时,可以使用状态模式。通过将这些条件分支转移到单独的状态对象中,可以消除复杂的条件逻辑,使代码更加清晰和可维护。
  3. 状态转换逻辑:当状态转换逻辑与状态表示的逻辑混合在一起时,可以使用状态模式将两者分离。这样做有助于减少代码的耦合度,并使状态转换逻辑更加明确和易于管理。

  与其他设计模式的对比:

  1. 策略模式(Strategy Pattern):策略模式与状态模式在结构上有相似之处,因为它们都使用上下文和可互换的行为(策略或状态)。然而,策略模式中的策略通常是客户端选择的,而状态模式中的状态转换是由上下文自身基于其当前状态来管理的。
  2. 模板方法模式(Template Method Pattern):状态模式可以被视为模板方法模式的一种扩展,其中“模板”由多个状态对象组成,每个状态对象处理上下文在特定状态下的行为。
  3. 有限状态机(Finite-State Machine):状态模式是实现有限状态机的一种方式,有限状态机是一种数学模型,用于设计计算机程序和算法,其中的对象具有有限数量的状态,并在触发事件时从一个状态转换到另一个状态。

四、总结

在这里插入图片描述

4.1 优点

  1. 清晰的状态转换逻辑:状态模式将状态转换逻辑封装在状态类中,使得状态转换更加清晰和可预测。每个状态类只关心自己的行为和转换条件,降低了代码的复杂性。
  2. 减少条件语句的使用:通过将条件逻辑分散到各个状态类中,状态模式避免了在上下文类中使用大量的条件语句。这提高了代码的可读性和可维护性。
  3. 更好的封装性和扩展性:状态模式允许将状态和与状态相关的行为封装在一起,这有助于隔离变化。当需要添加新的状态或行为时,只需添加新的状态类,而不需要修改现有的代码。

4.2 缺点

  1. 类爆炸问题:如果一个对象有很多状态,并且每个状态的行为差异很大,那么可能需要为每个状态创建一个单独的类。这可能导致系统中类的数量急剧增加,增加系统的复杂性。
  2. 状态转换的复杂性:虽然状态模式将状态转换逻辑分散到各个状态类中,但这也可能导致状态转换变得复杂和难以管理。特别是当状态转换涉及多个条件和步骤时,需要仔细设计状态类和转换逻辑。

3.3 挑战和限制

  1. 确定合适的状态和转换:在使用状态模式时,需要仔细分析对象的行为和状态变化,以确定合适的状态和转换条件。这可能需要深入的领域知识和对业务需求的准确理解。
  2. 处理状态共享行为:有时不同的状态可能具有一些共享的行为。在这种情况下,需要避免代码重复和不必要的类继承。可以通过使用共享的行为接口或抽象类来解决这个问题。
  3. 同步状态和数据:当使用状态模式时,需要确保上下文和状态对象之间的数据同步。状态对象可能需要访问上下文中的某些数据来执行其行为,因此需要确保这些数据在状态转换过程中保持一致。
  4. 处理异步事件和并发:在并发环境中使用状态模式时,需要特别注意处理异步事件和并发访问。可能需要使用同步机制来确保状态转换的原子性和一致性。

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

如若内容造成侵权/违法违规/事实不符,请联系瞎胡闹网进行投诉反馈,一经查实,立即删除!

相关文章

HCIA-HarmonyOS设备开发认证V2.0-IOT硬件子系统-WatchDog

目录 一、 WATCHDOG 概述功能简介基本概念 二、WATCHDOG 模块相关API三、WATCHDOG HDF驱动开发3.1、开发步骤(待续...) 坚持就有收获 一、 WATCHDOG 概述 功能简介 看门狗(Watchdog),又称看门狗计时器(Watchdog timer&#xff0…

零基础学编程,编程简单学,中文编程工具下载及工具箱进度条构件的用法

一、前言 今天给大家分享的中文编程开发语言工具 进度条构件的用法。 编程入门视频教程链接 https://edu.csdn.net/course/detail/39036 编程工具及实例源码文件下载可以点击最下方官网卡片——软件下载——常用工具下载——编程工具免费版下载及实例源码下载。 进度条 进度…

涵盖5大领域的机器学习工具介绍

随着数据的产生及其使用量的不断增加,对机器学习模型的需求也在成倍增加。由于ML系统包含了算法和丰富的ML库,它有助于分析数据和做出决策。难怪机器学习的知名度越来越高,因为ML应用几乎主导了现代世界的每一个方面。随着企业对这项技术的探…

信息检索(二):Dense Passage Retrieval for Open-Domain Question Answering

Dense Passage Retrieval for Open-Domain Question Answering 摘要1. 引言2. 背景3. DPR4. 实验设置5. 实验:文章检索6. 实验:问题问答7. 相关工作8. 结论参考资料 原文链接:https://aclanthology.org/2020.emnlp-main.550.pdf DPR 最早引入…

六、回归与聚类算法 - K-means算法

目录 1、K-means 聚类步骤 2、API 3、案例 4、性能评估指标 5、总结 线性回归欠拟合与过拟合线性回归的改进 - 岭回归分类算法:逻辑回归模型保存与加载无监督学习:K-means算法 1、K-means 聚类步骤 2、API 3、案例 4、性能评估指标 5、总结

【数据结构与算法初学者指南】【冲击蓝桥篇】String与StringBuilder的区别和用法

🎉🎉欢迎光临🎉🎉 🏅我是苏泽,一位对技术充满热情的探索者和分享者。🚀🚀 🌟特别推荐给大家我的最新专栏《数据结构与算法:初学者入门指南》📘&am…

【 JS 进阶 】Web APIs (一)

“生命是一曲奇妙的交响,每一段都是挑战,每一个音符都是机遇。在激情的旋律中,用勇气弹奏,创造出属于自己的华彩人生。” - 贝多芬 了解 DOM 的结构并掌握其基本的操作,体验 DOM 的在开发中的作用 知道 ECMAScript 与 …

基于SpringBoot的家教管理系统

基于SpringBootVue的家教管理系统的设计与实现~ 开发语言:Java数据库:MySQL技术:SpringBootMyBatis工具:IDEA/Ecilpse、Navicat、Maven 系统展示 前台主页 家教 个人中心 管理员界面 摘要 本文介绍了基于SpringBoot框架开发的家…

【深度学习笔记】3_5 图像分类数据集fashion-mnist

注:本文为《动手学深度学习》开源内容,仅为个人学习记录,无抄袭搬运意图 3.5 图像分类数据集(Fashion-MNIST) 在介绍softmax回归的实现前我们先引入一个多类图像分类数据集。它将在后面的章节中被多次使用&#xff0c…

论文是怎么一回事

最近找到女朋友了,她还挺关心我毕业和论文的事情,我开始着手弄论文了~ 说来惭愧,我一直以为读研就是做东西当作工作来完成,结果一直陷入如何实现的问题,结果要论文时不知道怎么弄创新点,这才转过头来弄论文…

信号系统之线性图像处理

1 卷积 图像卷积的工作原理与一维卷积相同。例如,图像可以被视为脉冲的总和,即缩放和移位的delta函数。同样,线性系统的特征在于它们如何响应脉冲。也就是说,通过它们的脉冲响应。系统的输出图像等于输入图像与系统脉冲响应的卷积…

重点媒体如何投稿?考核稿件投稿指南

传媒如春雨,润物细无声,大家好,我是51媒体网胡老师。 机构组织,国企央企都需要定期将相关新闻投递到央媒,官媒,或者地方重点媒体中,那么如何进行投稿了,今天就与大家分享下。 央媒投…

喝多少瓶汽水

喝多少瓶汽水 题目描述:解法思路:解法代码:运行结果: 题目描述: 水已知1瓶汽水1元,2个空瓶可以换⼀瓶汽水,输入整数n(n>0),表示n元钱,计算可以多少汽水&a…

《Docker 简易速速上手小册》第2章 容器和镜像(2024 最新版)

文章目录 2.1 理解 Docker 容器2.1.1 重点基础知识2.1.2 重点案例:使用 Docker 运行 Python 应用2.1.3 拓展案例 1:Docker 中的 Flask 应用2.1.4 拓展案例 2:Docker 容器中的数据分析 2.2 创建与管理 Docker 镜像2.2.1 重点基础知识2.2.2 重点…

力扣 169. 多数元素

思路: 因为题目说一定存在多数元素,就说明一定有一个数的个数多于n/2 将数组采用冒泡从小到大排序,最中间的那个元素一定是多数元素(因为在大小排好序后,中位数也一定是众数) 答案: int maj…

Xcode中App图标和APP名称的修改

修改图标 选择Assets文件 ——> 点击Applcon 换App图标 修改名称 点击项目名 ——> General ——> Display Name

C++中的STL数据结构

内容来自:代码随想录:哈希表理论基础 1.常见的三种哈希结构 当我们想使用哈希法来解决问题的时候,我们一般会选择如下三种数据结构 数组 set (集合) map(映射) 在C中,set 和 map 分别提供以下三种数据结构…

C++ 学习之Map容器

C++ Map容器概念 C++的Map容器是一种关联容器,它提供了一种将键和值相关联的方式。它以键值对的形式存储数据,并根据键的顺序自动进行排序。 Map中的键是唯一的,而值可以重复。你可以使用键来访问对应的值,就像使用索引访问数组中的元素一样。 Map容器的特点如下: 按照…

leetcode单调栈

739. 每日温度 请根据每日 气温 列表,重新生成一个列表。对应位置的输出为:要想观测到更高的气温,至少需要等待的天数。如果气温在这之后都不会升高,请在该位置用 0 来代替。 例如,给定一个列表 temperatures [73, …

29. 【Linux教程】Linux 用户介绍

本小节介绍 Linux 用户的基础知识,了解 Linux 系统中有哪些用户,如何查看当前 Linux 系统中有哪些用户,每一个 Linux 用户的权限取决于这些账号登录时获取到的权限。 1. Linux 用户类型 Linux 系统是一个多用户多任务的操作系统,…