java代码优化:判断内聚到实体对象中和构造上下文对象传递参数

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 通过两个常见的java后端实例场景探讨代码优化,代码不是优化出来的,而是设计出来的,我们永远不可能有专门的时间去做代码优化,优化和设计在平时

通过两个常见的java后端实例场景探讨代码优化,代码不是优化出来的,而是设计出来的,我们永远不可能有专门的时间去做代码优化,优化和设计在平时。

案例一:判断内聚到实体对象中

需求是数据库里会定期插入一些订单,需要在批处理服务中定时去扫描一下库里的数据,如果状态是未关闭且创建的时间超过1天,就把状态自动改成已关闭,核心代码如下:

public void closeOrder(List<OrderDO> orderList) {
   
    for (OrderDO orderDO : orderList) {
   
        if (!DateTimeUtils.isBeforeNowByDay(orderDO.getCreateTime(), 1)) {
   
            continue;
        }

        // 状态改成已关闭(这里直接修改状态简单模拟下)
        orderDO.setStatus(2);
    }
}

OrderDO.java

/**
 * 订单DO对象
 *
 * @author cafehaus
 * @date 2025/01/03
 */
@Data
public class OrderDO {
   
    /**
     * 订单id
     */
    private String orderId;

    /**
     * 状态:1-未关闭 2-已关闭
     */
    private Integer status;

    /**
     * 创建时间
     */
    private LocalDateTime createTime;
}

DateTimeUtils.java

/**
 * 日期时间工具类
 *
 * @author cafehaus
 * @date 2025/01/03
 */
public class DateTimeUtils {
   
    /**
     * 判断给定日期时间是否比当前早指定的天数
     *
     * @param date
     * @param gapDay
     * @return
     */
    public static boolean isBeforeNowByDay(LocalDateTime date, int gapDay) {
   
        if (date == null) {
   
            throw new IllegalArgumentException("LocalDateTime cannot be null");
        }

        // 要对比的参考时间:当前时间减去间隔的天数
        LocalDateTime referenceDate = LocalDateTime.now().minusDays(gapDay);

        // 返回比较结果
        return date.isBefore(referenceDate);
    }

}

上面的代码看着好像没啥问题,逻辑也很清晰。实际 for 循环里的那个 if 判断是可以继续优化的,按照上面的写法有两个不好的地方:

  • 单测不好测试
  • 判断不够简洁

下面是优化过后的代码:

public void closeOrder(List<OrderDO> orderList) {
   
    for (OrderDO orderDO : orderList) {
   
        if (orderDO.notNeedClose()) {
   
            continue;
        }

        // 状态改成已关闭(这里直接修改状态简单模拟下)
        orderDO.setStatus(2);
    }
}

OrderDO.java

/**
 * 订单DO对象
 *
 * @author cafehaus
 * @date 2025/01/03
 */
@Data
public class OrderDO {
   
    /**
     * 订单id
     */
    private String orderId;

    /**
     * 状态:1-未关闭 2-已关闭
     */
    private Integer status;

    /**
     * 创建时间
     */
    private LocalDateTime createTime;

    /**
     * 判断是否不需要关闭当前订单
     */
    public boolean notNeedClose() {
   
        return !DateTimeUtils.isBeforeNowByDay(createTime, 1);
    }
}

改动的地方只是直接将 if 判断内聚到了 DO 对象中作为一个方法,外部使用的时候直接调用一下当前对象的这个方法就可以了,也不需要再额外取反。除此之外,单测或者变异测试也很好测试,不需要再依赖整个流程或者其他数据,我们可以在任何地方直接 new 出来 OrderDO 对象,然后随便测试,外面的业务代码逻辑也变得更简单。

所以平时我们定义实体对象、枚举这些并不是只用 get、set 就行了,一些 if 判断实际内聚到实体对象内部更加合理,整体代码可读性也会提高不少。

案例二:构造上下文对象传递参数

在一个任务操作中,我们可能会先查询任务信息,然后参数、逻辑校验这些,接着进行具体的核心发布逻辑操作,最后可能还需要记录操作日志...其实和我们大部分的业务场景很相似,一个接口中我们需要拆解成很多步骤,为了代码的可读性,每个步骤我们可能又会提取成一个单独的方法,那其中就会涉及到各种参数、数据的传递,这个时候可能有如下几种解决办法:

  • 直接往方法中加参数,但是参数一多就会出问题了,一般超过3个参数就不建议直接传递了
  • 用 Map 来传递参数,但这样其实就违背了面向对象的初衷
  • 定义各种 DTO 之类的实体对象来传递和接收参数,如此就会写出下面的代码:

TaskService.java

public class TaskService {
   
    @Autowired
    private TaskRepositoryService taskRepositoryService;

    /**
     * 提交发布信息
     *
     * @param taskId
     * @param operateUser
     * @return
     */
    public String submitPublish(String taskId, String operateUser) {
   
        // 1. 查询任务信息
        TaskDTO taskDTO = taskRepositoryService.queryTaskById(taskId);

        // 2. 发布任务
        PublishResultDTO publishResultDTO = publishTask(taskDTO, operateUser);

        // 3. 记录日志
        insertPublishLog(taskDTO, operateUser, publishResultDTO);

        return taskDTO.getTaskId();
    }

    /**
     * 发布任务
     *
     * @param taskDTO
     * @param operateUser
     * @return
     */
    private PublishResultDTO publishTask(TaskDTO taskDTO, String operateUser) {
   
        PublishResultDTO result = new PublishResultDTO();

        try {
   
            // ... 省略掉了各种业务逻辑操作
            result.setResultCode("1");
            result.setResultMsg("success");
        } catch(Exception e) {
   
            result.setResultCode(e.getCode());
            result.setResultMsg(e.getMessage());
        }

        return result;
    }

    /**
     * 插入发布日志
     *
     * @param taskDTO
     * @param operateUser
     * @param publishResultDTO
     */
    private void insertPublishLog(TaskDTO taskDTO, String operateUser, PublishResultDTO publishResultDTO) {
   
        // 通过任务信息和发布结果构造日志数据插入数据库中,具体逻辑省略...
    }
}

TaskDTO.java

/**
 * 任务DTO对象
 *
 * @author cafehaus
 * @date 2025/01/04
 */
@Data
public class TaskDTO {
   
    /**
     * 任务id
     */
    private String taskId;

    /**
     * 任务步骤
     */
    private Integer publishStep;

    /**
     * 发布code
     */
    private String resultCode;

    /**
     * 发布结果信息
     */
    private String resultMsg;
}

PublishResultDTO.java

/**
 * 任务发布结果DTO对象
 *
 * @author cafehaus
 * @date 2025/01/04
 */
@Data
public class PublishResultDTO {
   
    /**
     * 发布code
     */
    private String resultCode;

    /**
     * 发布结果信息
     */
    private String resultMsg;
}

如果按照上面的写法,一个接口我们可能需要定义很多个 DTO 之类的接口来传递参数,如果一直按照这样去开发需求,经过一段时间之后就会发现项目中定义了一大堆各种各样的 DTO,那有没有其他可以优化的方式呢?

其实像这种一个接口中我们需要各种传递参数的场景,本身又在一个方法中那就可以通过构造一个统一的上下文对象来解决,如下是优化后的代码:

TaskService.java

public class TaskService {
   
    @Autowired
    private TaskRepositoryService taskRepositoryService;

    /**
     * 提交发布信息
     *
     * @param taskId
     * @param operateUser
     * @return
     */
    public String submitPublish(String taskId, String operateUser) {
   
        // 1. 构造上下文对象
        TaskContextDTO taskContextDTO = new TaskContextDTO();
        taskContextDTO.setTaskId(taskId);
        taskContextDTO.setOperateUser(operateUser);

        // 2. 查询任务信息
        TaskDTO taskDTO = taskRepositoryService.queryTaskById(taskId);
        taskContextDTO.setTaskInfo(taskDTO);

        // 3. 发布任务
        publishTask(taskContextDTO);

        // 4. 记录日志
        insertPublishLog(taskContextDTO);

        return taskContextDTO.getTaskId();
    }

    /**
     * 发布任务
     *
     * @param taskContextDTO
     */
    private void publishTask(TaskContextDTO taskContextDTO) {
   
        try {
   
            // ... 省略掉了各种业务逻辑操作
            taskContextDTO.setResultCode("1");
            taskContextDTO.setResultMsg("success");
        } catch(Exception e) {
   
            taskContextDTO.setResultCode(e.getCode());
            taskContextDTO.setResultMsg(e.getMessage());
        }
    }

    /**
     * 插入发布日志
     *
     * @param taskContextDTO
     */
    private void insertPublishLog(TaskContextDTO taskContextDTO) {
   
        // 通过任务信息和发布结果构造日志数据插入数据库中,具体逻辑省略...
    }
}

TaskContextDTO.java

/**
 * 任务上下文DTO对象
 *
 * @author cafehaus
 * @date 2025/01/04
 */
@Data
public class TaskContextDTO {
   
    /**
     * 任务id
     */
    private String taskId;

    /**
     * 操作人
     */
    private String operateUser;

    /**
     * 发布code
     */
    private String resultCode;

    /**
     * 发布结果信息
     */
    private String resultMsg;

    /**
     * 任务信息
     */
    private TaskDTO taskInfo;
}

所有参数的传递和接收全部通过一个 TaskContextDTO 对象解决,像 TaskDTO 里的信息也可以作为上下文对象里的一个属性来嵌套储存,利用引用数据类型的特点,前面的步骤也不需要 return 出结果再传给后面的步骤去获取了,在获取到结果时直接去 set 上下文对象 TaskContextDTO,其他需要的地方通过 get 就能直接获取到。如此方法的参数也减少了,也不需要再传来传去了。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
3天前
|
存储 Java
Java中判断一个对象是否是空内容
在 Java 中,不同类型的对象其“空内容”的定义和判断方式各异。对于基本数据类型的包装类,空指对象引用为 null;字符串的空包括 null、长度为 0 或仅含空白字符,可通过 length() 和 trim() 判断;集合类通过 isEmpty() 方法检查是否无元素;数组的空则指引用为 null 或长度为 0。
|
23天前
|
Java
Java快速入门之类、对象、方法
本文简要介绍了Java快速入门中的类、对象和方法。首先,解释了类和对象的概念,类是对象的抽象,对象是类的具体实例。接着,阐述了类的定义和组成,包括属性和行为,并展示了如何创建和使用对象。然后,讨论了成员变量与局部变量的区别,强调了封装的重要性,通过`private`关键字隐藏数据并提供`get/set`方法访问。最后,介绍了构造方法的定义和重载,以及标准类的制作规范,帮助初学者理解如何构建完整的Java类。
|
22天前
|
安全 Java
Object取值转java对象
通过本文的介绍,我们了解了几种将 `Object`类型转换为Java对象的方法,包括强制类型转换、使用 `instanceof`检查类型和泛型方法等。此外,还探讨了在集合、反射和序列化等常见场景中的应用。掌握这些方法和技巧,有助于编写更健壮和类型安全的Java代码。
35 17
|
3月前
|
安全 Java 编译器
Java对象一定分配在堆上吗?
本文探讨了Java对象的内存分配问题,重点介绍了JVM的逃逸分析技术及其优化策略。逃逸分析能判断对象是否会在作用域外被访问,从而决定对象是否需要分配到堆上。文章详细讲解了栈上分配、标量替换和同步消除三种优化策略,并通过示例代码说明了这些技术的应用场景。
Java对象一定分配在堆上吗?
|
3天前
|
安全 Java 程序员
Java 面试必问!线程构造方法和静态块的执行线程到底是谁?
大家好,我是小米。今天聊聊Java多线程面试题:线程类的构造方法和静态块是由哪个线程调用的?构造方法由创建线程实例的主线程调用,静态块在类加载时由主线程调用。理解这些细节有助于掌握Java多线程机制。下期再见! 简介: 本文通过一个常见的Java多线程面试题,详细讲解了线程类的构造方法和静态块是由哪个线程调用的。构造方法由创建线程实例的主线程调用,静态块在类加载时由主线程调用。理解这些细节对掌握Java多线程编程至关重要。
30 13
|
3天前
|
安全 Java 开发者
【JAVA】封装多线程原理
Java 中的多线程封装旨在简化使用、提高安全性和增强可维护性。通过抽象和隐藏底层细节,提供简洁接口。常见封装方式包括基于 Runnable 和 Callable 接口的任务封装,以及线程池的封装。Runnable 适用于无返回值任务,Callable 支持有返回值任务。线程池(如 ExecutorService)则用于管理和复用线程,减少性能开销。示例代码展示了如何实现这些封装,使多线程编程更加高效和安全。
|
1月前
|
监控 Java
java异步判断线程池所有任务是否执行完
通过上述步骤,您可以在Java中实现异步判断线程池所有任务是否执行完毕。这种方法使用了 `CompletionService`来监控任务的完成情况,并通过一个独立线程异步检查所有任务的执行状态。这种设计不仅简洁高效,还能确保在大量任务处理时程序的稳定性和可维护性。希望本文能为您的开发工作提供实用的指导和帮助。
104 17
|
2月前
|
Java
Java—多线程实现生产消费者
本文介绍了多线程实现生产消费者模式的三个版本。Version1包含四个类:`Producer`(生产者)、`Consumer`(消费者)、`Resource`(公共资源)和`TestMain`(测试类)。通过`synchronized`和`wait/notify`机制控制线程同步,但存在多个生产者或消费者时可能出现多次生产和消费的问题。 Version2将`if`改为`while`,解决了多次生产和消费的问题,但仍可能因`notify()`随机唤醒线程而导致死锁。因此,引入了`notifyAll()`来唤醒所有等待线程,但这会带来性能问题。
Java—多线程实现生产消费者
|
1月前
|
缓存 安全 算法
Java 多线程 面试题
Java 多线程 相关基础面试题
|
2月前
|
安全 Java Kotlin
Java多线程——synchronized、volatile 保障可见性
Java多线程中,`synchronized` 和 `volatile` 关键字用于保障可见性。`synchronized` 保证原子性、可见性和有序性,通过锁机制确保线程安全;`volatile` 仅保证可见性和有序性,不保证原子性。代码示例展示了如何使用 `synchronized` 和 `volatile` 解决主线程无法感知子线程修改共享变量的问题。总结:`volatile` 确保不同线程对共享变量操作的可见性,使一个线程修改后,其他线程能立即看到最新值。

热门文章

最新文章