工厂中pecs原则要求：返回值用
在工厂模式中使用泛型工厂 GenericFactory 时，PECS 原则直接影响构造参数类型声明的合理性与安全性——关键不在于工厂类本身是否泛型，而在于它接收什么、返回什么、以及如何约束输入输出边界。
✅ 工厂方法的返回类型：用 extends T>（Producer Extends）
当 GenericFactory 的职责是创建并返回具体子类实例（即“生产者”），其返回值应体现协变性：
public interface GenericFactory<t> {
T create(); // 直接返回 T，最清晰
}
// 或更灵活地支持多种子类构建：
public static <t> T createInstance(Class extends T> clazz) { ... }</t></t>
但若工厂方法返回一个集合或容器（如缓存池、对象列表），此时需明确声明产出边界：
public List extends Product> produceProducts() { ... }
- ✅ 合理：调用方能安全读取
Product或其子类（如Book、Electronics）； - ❌ 禁止添加：
list.add(new Book())编译失败 —— 因编译器无法确认?具体是哪个子类型，防止类型污染。
本质：工厂作为数据提供方，只对外暴露“可读不可写”的上界类型。
✅ 工厂方法的入参类型：用 super T>（Consumer Super）
当工厂需要接收配置、模板、或原型对象来生成实例（即“消费者”），参数应允许传入 T 及其任意父类：
public <u extends t> void configureWith(U prototype) { ... }
// 更通用写法（尤其用于构建器模式）：
public void buildFrom(Config super Product> config) { ... }</u>
常见场景：
- 注入一个通用配置器（如
Config<object></object>或Config<product></product>）来初始化不同子类； - 接收
Supplier super Product>作为实例化逻辑的委托；
public class GenericFactory<t> {
private final Supplier super T> initializer;
public GenericFactory(Supplier super T> init) {
this.initializer = init; // 注意：Supplier 的泛型是逆变的，此处 super 合理
}
}</t>
- ✅ 安全：可传入
Supplier<product></product>、Supplier<object></object>； - ❌ 不能从中获取
T实例（initializer.get()返回类型是? super T，不确定具体类型）——符合“只消费不产出”语义。
⚠️ 工厂内部泛型参数设计：避免无界通配符 >
不要这样写：
public void register(Class> clazz) { ... } // 太宽泛，失去类型关联
而应结合上下文绑定：
- 若注册的是可创建的类型（生产者视角）：
public <u extends t> void register(Class<u> clazz) { ... }</u></u> - 若注册的是可接受的输入模板类（消费者视角）：
public void registerTemplate(Class super T> templateClass) { ... }
这样既保留类型推导能力，又满足 PECS 对读/写边界的划分。
? 小结：工厂中 PECS 的落点逻辑
| 场景 | 类型声明 | 原因说明 |
|---|---|---|
| 返回具体对象或对象集合 |
T 或 List extends T>
|
工厂产出数据 → 是 Producer → 用 extends
|
| 接收配置、模板、原型 |
Class super T> 或 Supplier super T>
|
工厂消费输入 → 是 Consumer → 用 super
|
| 泛型工厂类自身声明 |
GenericFactory<t></t>（非通配符） |
需要稳定类型锚点，通配符仅用于方法参数/返回值 |
不复杂但容易忽略：工厂不是“泛型容器”，而是“类型契约执行者”。PECS 不是语法装饰，而是对数据流向的显式建模——产出生效于 extends，消费生效于 super。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
