Java 不允许将Collection<Car> 作为Collection<Vehicle> 的子类型。这是因为Collection<Car> 不能用来代替每个Collection<Vehicle>，因为Collection<Vehicle> 可能包含其他车辆子类型的元素，例如摩托车，因此它违反了里氏替换原则？
【问题讨论】：
标签： java collections liskov-substitution-principle subtyping
通常，Collections 由于存在“可选操作”而违反了 Liskov 替换原则，即变异方法可能无法用于特定实现。
然而，关于类型安全，它是这样工作的：
假设Car 是Vehicle 的子类型，Collection<Car> 是允许类似操作的类型
Collection<Car> c=…;
Car car=c.iterator().next();
Collection<Vehicle> 没有。另一方面，Collection<Vehicle> 是一种允许类似操作的类型
Collection<Vehicle> c=…;
Vehicle v=…;
c.add(v);
Collection<Car> 没有。因此，这些Collection 类型都不是另一个的子类型。
【讨论】：
不完全是。反过来：
Collection<Car> 仅包含 Cars 很好，即使 Collection<Vehicle> 可能包含其他类型的车辆。您仍然可以将Collection<Car> 提供给任何可以处理来自Collection<Vehicle> 的元素的人。
但Collection<Car> 不能用于代替Collection<Vehicle>，因为您可以将Bicycle 放入Collection<Vehicle>（但不能放入Collection<Car>）。所以你不能把Collection<Car>给想取车的人。
【讨论】：
Collection<T> 是一个类型构造函数，所以Collection<Car> 是一个类型，Collection<Vehicle> 是另一个类型。
现在的问题是，如果在需要 Collection<Vehicle> 的地方可以使用 Collection<Car>，这是一个方差问题（这种情况下是协方差）。
Liskov 替换原则在某种程度上超越了类型一致性，它不仅要求提供更多，要求更少，而且还保持超类型的合同，see Wikipedia。
【讨论】：
请注意，Collection<Car> 与组件类型 Car 相比不变。因此，如果您想使用汽车、自行车、火车等车辆的集合，您应该采用 协变 集合Collection<? extends Vehicle>。
当然，如果您有一个 CarFactory 和一个应该将生产的汽车停放在某个地方的生产方法，那么 逆变 produce(Collection<? super Car>) 方法将是最有用的实现。
【讨论】：