17370845950

本文对比 java 的使用点方差（wildcards）与 scala 的声明点方差，指出对于单职责接口（如 function），java 的通配符机制是冗余且易错的；而真正需要灵活方差控制的，是像 list 这样多用途、读写混合的复杂类型——但这类设计在现代函数式与面向对象实践中已逐渐被淘汰。

Java 的泛型系统采用使用点方差（use-site variance），即通过 ? extends T 或 ? super T 在方法签名中临时指定类型参数的方差行为。例如，Stream.map() 的声明：

 Stream map(Function mapper);

此处 ? super T 表达了输入类型的逆变性（子类可替代父类作为入参），? extends R 表达了返回类型的协变性（子类结果可安全视为父类结果）。这看似灵活，实则将本应由类型自身语义承载的方差契约，转移到每一次调用的语法细节中。

以 Function 为例：其唯一抽象方法 R apply(T t) 决定了 T 必然处于逆变位置（接受更宽泛的输入），R 必然处于协变位置（返回更具体的值）。因此，任何合法使用 Function 的场景，都天然要求 T 逆变、R 协变。Java 却仍允许用户写出 Function 并传入 Function

真正体现使用点方差“合理性”的，是像 List 这样的历史遗留泛型类型。它同时包含协变操作（E get(int)）和逆变操作（void add(E e)），导致 E 必须为不变（invariant）——即 List 不能赋值给 List

• List extends Number>：只读视图，可安全接收 List 或 List，支持 get()，禁止 add()；
• List super Integer>：只写视图，可安全接收 List 或 List

这种“按需投影接口”的

思路，在 Java 5 引入泛型时，是对已有庞大、粗粒度集合 API 的一种妥协性兼容方案。然而，这种设计与现代软件工程原则已明显脱节：

✅ SOLID 原则：今日推荐的是小而专注的接口（如 ReadOnlyList、WritableList），每个仅暴露单一职责的方法集；
✅ 不可变优先：List.of()、ImmutableList、Record 等使“只读”成为默认而非例外；
✅ 声明即契约：Scala 的 trait Function1[-T, +R] 或 trait Seq[+A] 将方差直接锚定在类型定义中，使用者无需记忆或推导每次调用的通配符规则——类型系统自动保障安全。

因此，结论并非“Java 方差机制更灵活”，而是：它曾为兼容旧设计而生，却在新范式下成为负担。对于新接口（如自定义函数式类型、事件处理器、转换器等），应优先采用声明点方差思维——即使 Java 语法不支持，也可通过命名与文档明确约束（如 Consumer super T> 作为字段类型），并借助静态分析工具（如 Error Prone）捕获误用。

简言之：通配符不是银弹，而是过渡时期的胶带；而真正的类型安全，来自清晰的接口划分与方差语义的早期绑定。