多态工具类的核心设计原则是用策略接口抽离可变逻辑，而非继承；工具方法应静态、泛型、接收策略实现，以保持无状态与高复用性。
多态工具类的核心设计原则
Java 多态本身不直接“提供”通用工具类，而是让你能用 interface 或 abstract class 定义统一行为契约，再让具体实现类按需扩展。真正通用的工具类（如 StringUtils、CollectionUtils）通常用静态方法 + 泛型，但若要“利用多态”，重点是把**可变逻辑抽离成策略接口**，而非把工具方法塞进继承树。
用 Strategy 模式替代“万能工具类”
硬写一个 UniversalTool 类并让它继承一堆子类，反而破坏单一职责。更合理的方式是定义策略接口，让调用方传入具体行为：
public interface DataProcessor<T> {
T process(String input);
}
<p>public class JsonProcessor implements DataProcessor<Map<String, Object>> {
@Override
public Map<String, Object> process(String input) {
// 使用 Jackson 或 Gson 解析
return new HashMap<>(); // 简化示意
}
}</p><p>public class NumberProcessor implements DataProcessor<Integer> {
@Override
public Integer process(String input) {
return Integer.parseInt(input.trim());
}
}</p><p>// 工具方法保持静态、泛型、接收策略
public class ProcessorUtils {
public static <T> T safeProcess(String input, DataProcessor<T> processor) {
try {
return processor.process(input);
} catch (Exception e) {
throw new IllegalArgumentException("Processing failed for: " + input, e);
}
}
}-
DataProcessor是多态入口，不同实现决定处理逻辑 -
ProcessorUtils.safeProcess是真正的“通用工具方法”，不耦合具体类型 - 调用时可传匿名类、Lambda 或预实例化对象：
safeProcess("123", new NumberProcessor())或safeProcess("{}", (s) -> {...})
避免在工具类中滥用继承
常见错误是定义 BaseTool，再派生 FileTool、DbTool、HttpTool，结果每个子类只重写一两个方法，其余全是重复的静态工具方法。这违背多态本意——多态用于“同一操作有不同实现”，不是用来组织零散功能的目录。
- 工具方法应尽量保持 无状态、静态、final，例如
Objects.requireNonNull() - 需要状态或上下文（如连接池、配置）时，用组合优于继承：把
HttpClient作为字段注入，而不是让工具类去继承它 - 若真要分层，优先用
interface+default method提供默认行为，而非抽象类
泛型 + 多态组合提升复用性
当工具需适配多种输入/输出类型，且行为差异由类型驱动时，结合泛型与策略接口最自然：
立即学习“Java免费学习笔记（深入）”；
public interface Converter<S, T> {
T convert(S source);
}
<p>public class StringToUserConverter implements Converter<String, User> {
@Override
public User convert(String json) { /<em> ... </em>/ }
}</p><p>public class StringToOrderConverter implements Converter<String, Order> {
@Override
public Order convert(String xml) { /<em> ... </em>/ }
}</p><p>public class ConvertUtils {
public static <S, T> T convert(S source, Converter<S, T> converter) {
return converter.convert(source);
}
}这种写法让调用方控制“怎么转”，工具类只负责“安全地转”。比写一堆 convertStringToUser()、convertStringToOrder() 方法更易维护，也天然支持新增类型而无需改工具类源码。
真正难的不是写多态，而是判断哪里该用多态——如果某个“工具”每次调用都要 if-else 切换逻辑，那它大概率该是个策略接口，而不是一个塞满 switch 的静态方法。
