答案。

问题背景

Java 从一开始就是作为一种面向对象的语言开发的，其主要任务是通过创建类实例来解决。但是，为了常用的方法（例如，排序、数据转换），出现了一些带有一组静态方法的工具类（例如 java.util.Collections）。

问题

静态方法简化了对辅助功能的调用，但不适合存储状态、依赖注入和隔离测试。另一方面，类实例更加灵活，但会增加初始化代码的数量，并要求更精心的生命周期管理。

解决方案

工具类（utility classes) — 一组无状态的静态方法，不需要创建对象。适合于对集合的操作、转换和数学运算。
类实例 — 存储状态，使用依赖，提供扩展性和可测试性。应用于业务逻辑、服务、控制器等。

代码示例：

// 工具类示例
public class MathUtils {
    public static int add(int a, int b) {
        return a + b;
    }
}

// 使用：int sum = MathUtils.add(1, 2);

// 业务逻辑类示例
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }
    public void placeOrder(Order o) {
        repo.save(o);
    }
}

关键特性：

无状态且不可在隔离中测试 — 工具类。
有状态的类可以通过依赖注入（DI）轻松替换。
工具类通常被声明为 final，并具有私有构造函数。

有陷阱的问题。

可以继承工具类并扩展其静态方法吗？

不可以，通常工具类被声明为 final，并具有私有构造函数。静态方法的继承是可能的，但没有意义，因为静态方法不能通过实例调用继承。

代码示例：

public final class MyUtils {
    private MyUtils() {} // 防止创建实例
}

工具类能否包含状态？

不可以。如果工具类包含状态（实例或静态字段），这违反了编写工具的原则，并导致多线程错误和可读性下降。

在测试时，可以模拟工具类的静态方法吗？

只能通过诸如 PowerMock 之类的特殊工具，这会使测试更加复杂，有时不稳定。在一般情况下，友好的 DI 方法使用实例更适合测试。

常见错误和反模式

违反单一职责原则：工具类开始存储状态。
继承或扩展工具类。
在需要状态管理的地方使用静态方法（例如，业务服务）。

生活中的例子

消极案例

在项目中，所有服务都是通过工具静态方法实现的。依赖注入不可行，单元测试没有隔离，每个测试都依赖于环境状态。

优点：

快速启动。
调用简单。

缺点：

缺乏可测试性。
责任划分问题。

积极案例

服务中使用单独的类进行依赖注入，通过接口。对于转换和简单操作，使用无状态的单独工具类。