本文介绍通过封装共享逻辑为独立类的方式，消除多个 lambda 函数中重复的初始化代码（如路径提取、值预处理、组织调用），从而提升代码复用性与可读性。
在 Java 函数式编程实践中，当多个 lambda 表达式（尤其是实现同一函数式接口的实例）存在相同前置逻辑时，硬编码重复不仅违反 DRY（Don’t Repeat Yourself）原则，还会增加维护成本和出错风险。以 OrganizerFunc 接口为例，organizeBooksFunc 和 organizeToysFunc 均需执行以下三步共用操作：
- 从 orgPath 提取路径字符串（orgPath.get()）；
- 对原始 value 进行前缀增强（PREFIX + value.get()）；
- 调用核心组织方法 callOrganizer(path, value) 获取 organizedValue。
这些逻辑与业务主流程无关，却散落在各 lambda 主体中，导致后续修改（如调整前缀策略或异常处理）需多处同步。
✅ 推荐方案：使用轻量 POJO 封装共享初始化逻辑
定义一个不可变（或仅含必要 setter）的辅助类 SharedOrganizeContext，将重复步骤封装为构造逻辑：
public class SharedOrganizeContext {
private final String path;
private final String value;
private final String organizedValue;
public SharedOrganizeContext(List orgPath, Schema schema, Value value) {
if (!schema.isOrganizable()) {
throw new IllegalArgumentException("Schema is not organizable");
}
this.path = orgPath.get(); // 假设 List 非空且 get() 返回 String
this.value = PREFIX + value.get();
this.organizedValue = callOrganizer(this.path, this.value);
}
// Getter 方法（推荐使用 Lombok @Data 或手动编写）
public String getPath() { return path; }
public String getValue() { return value; }
public String getOrganizedValue() { return organizedValue; }
} ? 注意：原答案中 SharedStuff 构造器参数类型有误（String schema 应为 Schema schema），且未校验 schema.isOrganizable() 的前置条件——该判断应在构造前由调用方控制，或在构造器内显式校验并抛出语义明确的异常，避免静默失败。
随后，在各业务方法中简洁复用：
public static void organizeBooks() {
OrganizerFunc organizeBooksFunc = (orgPath, schema, value) -> {
if (schema.isOrganizable()) {
SharedOrganizeContext ctx = new SharedOrganizeContext(orgPath, schema, value);
// ✅ 此后直接使用 ctx.getPath(), ctx.getValue(), ctx.getOrganizedValue()
// 执行书籍专属逻辑，例如：
Book book = new Book(ctx.getOrganizedValue());
persistBook(book, ctx.getPath());
}
};
}
public static void organizeToys() {
OrganizerFunc organizeToysFunc = (orgPath, schema, value) -> {
if (schema.isOrganizable()) {
SharedOrganizeContext ctx = new SharedOrganizeContext(orgPath, schema, value);
// ✅ 玩具专属逻辑，完全解耦公共初始化
Toy toy = Toy.from(ctx.getOrganizedValue());
archiveToy(toy, ctx.getPath());
}
};
}? 进阶建议：
立即学习“Java免费学习笔记（深入）”；
- 若未来需支持不同组织策略（如 Books 使用 callOrganizerV1，Toys 使用 callOrganizerV2），可将组织逻辑抽象为 Function
参数传入构造器，实现策略注入； - 对于更复杂的上下文，可考虑使用 Builder 模式或静态工厂方法提升可读性；
- 避免在 SharedOrganizeContext 中持有对 schema 或 orgPath 的强引用（除非必要），防止意外内存泄漏或状态污染。
通过这一设计，lambda 主体聚焦业务本质，重复逻辑集中管控，既符合函数式编程的清晰边界，又兼顾面向对象的封装优势。
