工具类无状态且提供静态方法，用于通用操作如字符串处理；普通类有状态和行为，支持实例化与继承。通过接口组合、注册机制、分层设计提升工具类扩展性，避免上帝类。按职责选择：无状态用工具类，需状态管理或可测试性则用普通类。
在Java开发中，工具类（Utility Class）和普通类承担不同的职责。正确区分二者，并设计可扩展的工具类结构，对代码的可维护性和复用性至关重要。
工具类与普通类的核心区别
工具类通常不维护状态，仅提供静态方法用于执行通用操作，比如字符串处理、日期格式化、数学计算等。它们是无实例化的，一般通过私有构造函数防止被实例化。
例如：
public final class StringUtils { private StringUtils() {} // 防止实例化 public static boolean isEmpty(String str) { return str == null || str.isEmpty(); } }普通类则代表业务实体或服务组件，通常包含状态（成员变量）和行为（方法），可以被实例化并参与依赖注入、继承、多态等面向对象特性。
立即学习“Java免费学习笔记（深入）”；
比如 User 类表示用户信息，Service 类封装业务逻辑。
关键差异总结：
- 工具类：无状态、全静态方法、不可变、不允许被继承
- 普通类：有状态、实例方法为主、可被扩展和继承
构建可扩展的工具类结构
虽然工具类以静态方法为主，但“扩展性”并不意味着让其支持继承（这违背工具类设计初衷），而是指在架构层面便于新增功能、替换实现或组合使用。
以下是几种提升扩展性的实践方式：
1. 接口+工具类组合（策略暴露）
将通用能力抽象为接口，工具类作为门面调用具体实现。这样可以在不修改工具类的前提下替换底层逻辑。
public interface Validator { boolean validate(String input); } public final class ValidationUtils { private static Validator defaultValidator = new DefaultValidator(); public static boolean isValid(String input) { return defaultValidator.validate(input); } public static void setValidator(Validator v) { defaultValidator = v; } }
2. 使用内部服务注册机制
允许运行时注册新的处理逻辑，适用于需要动态添加规则的场景，如格式化器、转换器。
public final class FormatterRegistry { private static final Map3. 工具类分层设计
避免“上帝工具类”，按功能拆分小而专的工具类，例如 DateUtils、CollectionUtils、FileUtils 等。再通过一个高层工具类聚合常用操作，保持清晰边界。
4. 利用 Java SPI 或 Spring 扩展点（高级场景）
在框架级工具中，可通过 Service Provider Interface（SPI）加载外部实现，实现插件化扩展。例如日志工具、序列化工具等。
何时该用工具类，何时该用普通类？
判断标准应基于职责：
- 如果是一组与特定类型无关的纯函数操作（如 null 判断、加密、编码），适合用工具类
- 如果涉及状态管理、配置、资源持有（如数据库连接池、缓存客户端），应设计为普通类
- 如果未来可能更换实现或需要 mock 测试，优先考虑普通类 + 接口，而非静态方法
注意：过度使用静态工具类会降低测试友好性，难以模拟依赖。在核心业务逻辑中，推荐依赖注入替代静态调用。
总结
工具类适用于无状态的通用功能封装，通过私有构造、静态方法、final修饰保证安全性和一致性。扩展性不靠继承，而靠设计模式（策略、注册、门面）和模块化组织来实现。合理区分工具类与普通类，能有效提升代码结构的清晰度和长期可维护性。
基本上就这些，不复杂但容易忽略。
