高度抽象的公共组件应聚焦单一可变行为，用函数式接口（如Function、Predicate、Consumer）封装变化点，通过泛型参数化、组合增强与default方法实现职责内聚、零侵入扩展和开箱即用。
编写高度抽象的公共组件，关键不在于堆砌接口数量，而在于精准识别可变行为、封装变化点，并让调用方只关心“做什么”，不关心“怎么做”。函数式接口是实现这一目标最轻量、最自然的载体。
聚焦单一可变行为，定义最小契约
高度抽象的前提是接口足够小、足够纯粹。一个函数式接口只应表达一种明确的计算意图，比如“从A转换为B”、“对某物执行某个动作”、“判断某条件是否成立”。避免把多个语义混在一个接口里。
例如，不要写一个叫 Processor 的接口去囊括转换、过滤、聚合；而是分别定义：
- Function<T, R> —— 表达“输入T，输出R”的纯转换逻辑
- Predicate<T> —— 表达“输入T，返回boolean”的判定逻辑
- Consumer<T> —— 表达“接收T，不返回结果”的副作用操作
这些JDK原生接口已通过泛型参数化，天然支持任意类型，无需重复造轮子。自定义时也应沿用相同命名习惯和语义，如 RetryPolicy<T>（决定是否重试）、IdGenerator<T>（生成某种ID），保持语义清晰、职责内聚。
立即学习“Java免费学习笔记（深入）”；
用泛型+函数式参数替代硬编码分支
公共组件中常见的“if-else适配不同场景”，本质是行为可变。此时应把分支逻辑外提为函数式参数，而非在组件内部写一堆 if (type == X)。
比如一个通用的数据导出服务：
- 差的做法：内部硬编码支持Excel、CSV、JSON，每加一种格式就要改源码
- 好的做法：定义 Exporter<T> 接口，要求实现 String export(List<T> data)；使用者传入 (data) -> toExcel(data) 或 JsonExporter::toJSON
这样组件本身不依赖任何具体格式实现，扩展零侵入，测试也只需 mock 一个 Lambda 即可验证主流程。
组合优于继承，用高阶函数增强能力
高度抽象的组件不是功能大而全，而是易于组装。利用函数式接口支持链式组合的特性，提供静态工具方法来增强行为。
例如：
- 给 Predicate<T> 加上缓存能力：Predicates.memoized(predicate)
- 给 Function<T, R> 加上异常包装：Functions.safely(fn, fallback)
- 将多个 Consumer<T> 合并为一个：Consumers.andThen(c1, c2, c3)
这些方法本身不持有状态，只接受函数式接口作为参数并返回新的函数式接口，完全符合引用透明性，也便于单元测试——你只需要验证组合逻辑是否正确，不用启动整个业务环境。
配套默认方法，隐藏常见实现细节
Java 8+ 接口支持 default 方法，这是提升抽象层次的利器。它能让接口既保持契约简洁，又提供开箱即用的便利实现。
比如定义一个日志策略接口：
public interface LogPolicy {
boolean shouldLog(Level level, String message);
default boolean shouldLogWarnOrAbove(Level level) {
return level.intValue() >= Level.WARNING.intValue();
}
default LogPolicy withRateLimit(int maxPerMinute) {
return new RateLimitedPolicy(this, maxPerMinute);
}
}
使用者可以直接用 policy.withRateLimit(10) 获得增强版策略，而无需了解限流的具体实现；底层类也可专注核心逻辑，复用默认方法降低模板代码量。
