本文详解为何MyArrayList
本文详解为何myarraylist extends shape>无法调用add()方法，揭示上界通配符（? extends t）在类型安全约束下的核心语义：它仅支持“读取”操作，禁止任何可能破坏类型一致性的“写入”操作。
在Java泛型中，? extends Shape 是一个上界通配符（Upper Bounded Wildcard），表示“某个未知的具体子类型，但该类型一定是 Shape 或其子类”。关键在于：这个“未知”是不可逆推、不可确定的——编译器只知道它属于 Shape 的某个子类型族，却无法确认究竟是 Circle、Rectangle 还是其他任意子类，甚至可能是未来新增的 Triangle。
因此，当你声明：
private static MyArrayList<? extends Shape> history = new MyArrayList<>();
你实际上创建了一个类型安全的只读容器引用。这里的 history 并非指向一个“能装任意 Shape 子类对象”的列表，而是指向一个“内部元素类型被固定为某个具体未知子类型（如 Circle 或 Rectangle）”的列表。这种设计源于泛型的不变性（invariance） 和 PECS 原则（Producer Extends, Consumer Super）：
- ✅ ? extends Shape 适合作为生产者（Producer）：你可以安全地从其中 get() 出元素，并将其视为 Shape（因为所有子类都可向上转型）；
- ❌ 它不能作为消费者（Consumer）：你无法向其中 add() 任何具体对象（包括 new Circle() 或 new Rectangle()），因为这会违反类型一致性——如果底层实际是 MyArrayList
，插入 Rectangle 就会破坏类型安全；而编译器必须保证任何合法调用在所有可能的具体类型下都成立。
以下代码清晰展示了这一限制：
立即学习“Java免费学习笔记（深入）”；
// 编译错误！无法添加任何具体子类实例 // history.add(new Circle()); // ❌ // history.add(new Rectangle()); // ❌ // 但可以安全读取并向上转型 Shape s1 = history.get(0); // ✅ 返回类型推断为 Shape（最宽上界）
⚠️ 常见误区澄清：
- MyArrayList extends Shape> ≠ MyArrayList
前者表示“某个特定子类型的列表”，后者表示“可容纳任意 Shape 子类实例的列表”。前者更严格、更安全，但牺牲了写入能力；后者允许写入，但需确保类型兼容性（如 Shape 必须是具体可实例化的类或有合适的构造逻辑）。 - List
- >（如前例）之所以可行，是因为外层 List 存储的是“列表对象”，而非 Shape 实例本身；内层每个 List extends Shape> 仍遵循只读规则，但外层操作不涉及对内层元素的写入。
✅ 正确实践方案：
若需构建可动态添加多种 Shape 子类实例的容器，请直接使用具体上界类型或原始类型（不推荐）：
// 方案1：使用具体上界（推荐）——允许添加任意 Shape 子类
private static MyArrayList<Shape> history = new MyArrayList<>();
public static void main(String[] args) {
history.add(new Circle()); // ✅
history.add(new Rectangle()); // ✅
System.out.println(history);
}
// 方案2：若必须保留通配符语义，改用无界通配符 + 显式类型检查（不常用）
// private static MyArrayList<?> history = new MyArrayList<Shape>();总结：? extends T 的本质是类型安全的协变视图，它强化了读取安全性，但以放弃写入灵活性为代价。理解这一点，是写出健壮、可维护泛型代码的关键基础。
