java 8+ 允许在接口中定义静态方法，但它们属于接口本身而非实现类；调用时必须通过接口名（如 builder.build(...)），不能通过实现类名（如 subrecipe.build(...)）访问。
java 8+ 允许在接口中定义静态方法，但它们属于接口本身而非实现类；调用时必须通过接口名（如 builder.build(...)），不能通过实现类名（如 subrecipe.build(...)）访问。
在 Java 中，接口中的 static 方法是接口层级的工具方法，其本质是“绑定到接口类型”的静态成员，而非继承给实现类的可调用成员。这与类的静态方法行为一致：静态方法不参与多态、不可被重写，也不随 implements 关系自动“注入”到实现类中。
因此，您定义的 Builder 接口中的两个泛型静态方法：
public interface Builder {
static <T extends Recipe> T build(File file) throws IOException {
String json = new String(Files.readAllBytes(Paths.get(file.getPath())));
return (T) T.build(new JSONObject(json)); // ⚠️ 注意：此处 T.build(...) 假设 Recipe 子类有静态 build(JSONObject) 方法
}
static <T extends Recipe> List<T> build(File[] files) throws IOException {
List<T> recipeList = new ArrayList<>();
for (File file : files) {
T r = build(file);
if (r != null) recipeList.add(r);
}
return recipeList;
}
}✅ 正确调用方式（推荐）：
直接通过接口名调用，无需实例化，也无需子类暴露同名静态方法：
// ✅ 正确：通过接口名调用
SubRecipe recipe = Builder.build(new File("/path/to/file.json"));
List<SubRecipe> recipes = Builder.build(new File[]{file1, file2});❌ 错误调用方式（编译失败）：
// ❌ 编译错误：SubRecipe 类中不存在静态方法 build(File)
SubRecipe recipe = SubRecipe.build(new File("...")); // 编译报错：cannot find symbol? 补充说明：T.build(...) 这一行存在潜在风险——它依赖于每个 Recipe 子类都提供一个 public static T build(JSONObject) 工厂方法。若未统一约定，会导致 ClassCastException 或 NoSuchMethodError。更健壮的设计应引入类型擦除安全的工厂函数，例如：
立即学习“Java免费学习笔记（深入）”；
static <T extends Recipe> T build(File file, Function<JSONObject, T> factory) throws IOException { JSONObject json = new JSONObject(Files.readString(Paths.get(file.getPath()))); return factory.apply(json); }调用时显式传入构造逻辑：
SubRecipe r = Builder.build(file, SubRecipe::fromJSON);
? 关键原则总结：
- 接口静态方法 ≠ 实现类静态方法：它们仅属于接口类型，不可被实现类“继承”或“覆盖”；
- 静态方法调用路径固定为 InterfaceName.method(...)，与实现类无关；
- 若需按子类语义定制构建逻辑，建议结合泛型 + 函数式参数（如 Supplier<T> 或 Function<..., T>），而非依赖类型强制转换；
- 默认方法（default）适用于需要访问实例状态的场景，而静态方法适用于无状态的通用工具逻辑——二者定位不同，不可互相替代。
综上，将构建逻辑封装在接口静态方法中是合理的设计，但务必遵循 Java 的调用契约：用接口调，不用实现类调。
