函数式接口通过契约清晰与行为外置支撑高内聚：将易变逻辑抽象为参数（如notificationhandler、freightcalculator），主类专注稳定骨架；复用java.util.function标准接口约束粒度；策略选择独立于业务类，确保单一职责。
函数式接口本身不直接实现高内聚，而是通过“契约清晰 + 行为外置”来支撑高内聚——它把主流程中易变、分散的逻辑剥离出去，让核心业务类只专注自身职责，不再掺杂多种实现细节。
聚焦单一职责，主流程不再承担分支判断
高内聚要求一个类只做一件事。传统写法常在服务类里堆砌 if-else 处理不同场景，比如订单处理时根据渠道决定发短信还是站内信，这会让 OrderService 同时承担流程控制、渠道适配、异常兜底等多重责任。
用函数式接口后，主方法只保留稳定骨架：
- 定义接口如 NotificationHandler：仅声明
void notify(Order order) - OrderService.process() 方法签名变为：
void process(Order order, NotificationHandler handler) - 内部只调用
handler.notify(order)，不出现任何渠道判断或 new 实例语句
把变化点变成参数，而非类内逻辑
哪些地方容易变，就把它抽象成函数式接口参数。这不是加一层包装，而是明确划出“稳定边界”和“可插拔区域”。
例如运费计算：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 不变的是“对订单算运费”这个动作，定义 FreightCalculator 接口
- 变的是规则（新用户免运费、VIP折上折、满额包邮），这些由外部传入 Lambda 或方法引用实现
- OrderService 不再有
if (user.isVip()) { ... } else if (order.isNew()) { ... }
复用标准接口，避免契约膨胀
高内聚也体现在接口设计本身是否精炼。优先使用 java.util.function 中的通用类型，能天然约束接口粒度：
- 无返回、只消费数据 → 用 Consumer
- 需返回布尔结果作判断 → 用 Predicate
- 需转换对象或计算数值 → 用 Function
这些接口方法语义明确、数量固定（只有一个抽象方法），不会因随意添加方法而破坏内聚性；同时省去自定义接口的维护成本。
配合策略选择机制，保持主类纯净
函数式接口不是孤立使用的。它常与策略识别逻辑配合，但识别部分应独立于业务主类：
- 用枚举或配置中心决定当前该用哪个 Lambda 表达式
- 或通过工厂方法封装选择逻辑，返回对应 Consumer/Function 实例
- OrderService 只接收已选好的处理器，不参与决策过程
这样，主业务类的职责始终是“执行订单流程”，而不是“判断该走哪条路”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
