如何利用Java多态编写通用的工具类

多态工具类的核心设计原则是用策略接口抽离可变逻辑，而非继承；工具方法应静态、泛型、接收策略实现，以保持无状态与高复用性。

多态工具类的核心设计原则

Java 多态本身不直接“提供”通用工具类，而是让你能用 interface 或 abstract class 定义统一行为契约，再让具体实现类按需扩展。真正通用的工具类（如 StringUtils、CollectionUtils）通常用静态方法 + 泛型，但若要“利用多态”，重点是把**可变逻辑抽离成策略接口**，而非把工具方法塞进继承树。

用 Strategy 模式替代“万能工具类”

硬写一个 UniversalTool 类并让它继承一堆子类，反而破坏单一职责。更合理的方式是定义策略接口，让调用方传入具体行为：

public interface DataProcessor {
    T process(String input);
}
public class JsonProcessor implements DataProcessor> {
@Override
public Map process(String input) {
// 使用 Jackson 或 Gson 解析
return new HashMap<>(); // 简化示意
}
}
public class NumberProcessor implements DataProcessor {
@Override
public Integer process(String input) {
return Integer.parseInt(input.trim());
}
}
// 工具方法保持静态、泛型、接收策略
public class ProcessorUtils {
public static  T safeProcess(String input, DataProcessor 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 提供默认行为，而非抽象类

泛型 + 多态组合提升复用性

当工具需适配多种输入/输出类型，且行为差异由类型驱动时，结合泛型与策略接口最自然：

用Delphi编写小型数据库 中文WORD版

本文档主要讲述的是用Delphi编写小型数据库；Delphi是目前最流行的编程工具之一，它在开发数据库应用程序方面有着众多的优越性，提供了强大的开发基于客户/服务器模式数据库应用程序的能力。在数据库访问方面，配有Borland Database Engine(BDE)，可通过SQL Links、ODBC等技术访问多种数据库，也可以利用ADO来访问各种数据库。在应用程序客户端开发方面，Delphi提供了大量的用于数据库应用开发的各种组件，可以极大地提高开发效率。希望本文档会给有需要的朋友带来帮助；感兴趣的朋

下载

立即学习“Java免费学习笔记（深入）”；

public interface Converter {
    T convert(S source);
}
public class StringToUserConverter implements Converter {
@Override
public User convert(String json) { / ... / }
}
public class StringToOrderConverter implements Converter {
@Override
public Order convert(String xml) { / ... / }
}
public class ConvertUtils {
public static  T convert(S source, Converter converter) {
return converter.convert(source);
}
}

这种写法让调用方控制“怎么转”，工具类只负责“安全地转”。比写一堆 convertStringToUser()、convertStringToOrder() 方法更易维护，也天然支持新增类型而无需改工具类源码。

真正难的不是写多态，而是判断哪里该用多态——如果某个“工具”每次调用都要 if-else 切换逻辑，那它大概率该是个策略接口，而不是一个塞满 switch 的静态方法。