前言：工具类，几乎是所有 Java 项目的“隐形技术债”
如果你维护过 三年以上的 Java 项目，那你一定对这些类名不陌生：
StringUtilsDateUtilValidationUtilCommonUtilsXXXHelper
它们通常位于类似这样的目录下：
/src/main/java/com/icoderoad/common/util刚开始，这些工具类简直是效率神器：一个 static 方法，随处可用，不用注入，不用配置。
但时间一长，你会发现问题开始失控：
- 方法越来越多，一个类动辄上百行
- 测试时无法 mock，只能硬测
- 逻辑被写死，想替换实现几乎等于重构
- 所有模块都“偷偷依赖”它，谁也不敢删
工具类从“捷径”，慢慢变成了项目的地雷区。
好消息是：从 Java 8 开始，我们终于有了一个更优雅、可组合、可测试的替代方案——函数式接口。
传统工具类模式：问题不在“能不能用”，而在“能不能演进”
我们先来看一个极其典型、甚至“教科书级”的工具类示例。
传统写法：静态校验工具类
packagecom.icoderoad.common.util;
publicfinalclassValidationUtil {
privateValidationUtil() {
}
publicstaticbooleanisValidEmail(Stringemail) {
returnemail!=null
&&email.matches("^[\\w.-]+@[\\w.-]+\\.\\w{2,}$");
}
publicstaticbooleanisValidPassword(Stringpassword) {
returnpassword!=null&&password.length() >=8;
}
}使用方式也非常直接：
if (!ValidationUtil.isValidEmail(email)) {
thrownewIllegalArgumentException("邮箱格式不合法");
}这种写法的问题，不是“不好用”
老实说，这段代码没有语法问题，也不算丑。但它在架构层面埋下了几个长期隐患：
1. 无法替换实现
- 校验规则写死在方法里
- 想改正则？只能改源码
- 不同场景（注册 / 后台 / 第三方同步）无法定制
2. 测试不友好
- 静态方法无法 mock
- 只能写集成测试
- 很难构造边界场景
3. 职责开始膨胀
今天是邮箱、密码明天是手机号、身份证后天是企业邮箱、国际号码
最后你会得到一个“上帝级校验工具类”。
换个思路：把“行为”当成参数，而不是写死在工具类里
Java 8 之后，函数式接口 + Lambda 本质上做了一件事：
把“规则”和“执行逻辑”从工具类中解放出来
定义一个“校验规则”的函数式接口
我们先从最小抽象开始。
packagecom.icoderoad.validation;
@FunctionalInterface
publicinterfaceValidator<T> {
booleanvalidate(Tvalue);
}这个接口的意义非常明确：
- 它不关心校验内容
- 只定义“校验行为”本身
用函数式接口替代 ValidationUtil
邮箱校验，不再是 static 方法
packagecom.icoderoad.validation.impl;
importcom.icoderoad.validation.Validator;
publicclassEmailValidator {
publicstaticfinalValidator<String>DEFAULT=
email->email!=null
&&email.matches("^[\\w.-]+@[\\w.-]+\\.\\w{2,}$");
}密码校验规则，也变成“可替换策略”
packagecom.icoderoad.validation.impl;
importcom.icoderoad.validation.Validator;
publicclassPasswordValidator {
publicstaticfinalValidator<String>MIN_LENGTH_8=
password->password!=null&&password.length() >=8;
}注意这里的变化：
- 没有工具类
- 没有 static 方法堆叠
- 每个规则都是一个清晰的、可组合的行为对象
在业务代码中使用：不依赖工具类，也不耦合实现
packagecom.icoderoad.service;
importcom.icoderoad.validation.Validator;
publicclassUserService {
privatefinalValidator<String>emailValidator;
privatefinalValidator<String>passwordValidator;
publicUserService(Validator<String>emailValidator,
Validator<String>passwordValidator) {
this.emailValidator=emailValidator;
this.passwordValidator=passwordValidator;
}
publicvoidregister(Stringemail, Stringpassword) {
if (!emailValidator.validate(email)) {
thrownewIllegalArgumentException("邮箱格式错误");
}
if (!passwordValidator.validate(password)) {
thrownewIllegalArgumentException("密码不符合规则");
}
}
}你现在得到的能力是：
- 校验规则可注入
- 单元测试可 mock
- 不同环境可用不同实现
- 没有“万能工具类”
Lambda 直写：甚至连实现类都可以不要
如果规则足够简单，实现类本身都可以消失：
Validator<String>emailValidator=
email->email!=null&&email.contains("@");
Validator<String>passwordValidator=
pwd->pwd!=null&&pwd.length() >=12;这在测试代码、临时规则、A/B 实验中非常有价值。
这不是“语法升级”，而是设计层级的变化
你真正得到的，并不是 Lambda 的“简洁”，而是：
对比维度 | 工具类 | 函数式接口 |
可测试性 | 否 | 是 |
可替换性 | 否 | 是 |
组合能力 | 否 | 是 |
代码演进成本 | 高 | 低 |
架构灵活度 | 固定 | 可扩展 |
工具类是“过程式思维”的产物，函数式接口是“行为建模”的开始。
结语：别再问“要不要删工具类”，而是“它还能不能活下去”
这篇文章并不是在说：
“工具类一律是错的”
而是想强调一件事：
当一个工具类开始承载“规则”“策略”“业务判断”时，它就已经不再适合存在了。
函数式接口并不是炫技，它解决的是：
- 老项目如何平滑演进
- 如何降低重构成本
- 如何让代码更接近“可组合系统”
如果你正在维护一个充满 Utils、Helper、Common 的老项目——不妨从最容易失控的校验逻辑开始，给它做一次温和但彻底的升级。
下一步，你会发现：代码不是被“重写”，而是在“进化”。
