集合子类型-Liskov替换原理
Java不允许收集
共有3个答案
集合
现在的问题是，如果一个集合
Liskov替换原则在某种程度上超越了类型一致性，它不仅要求提供更多，要求更少，而且还要求保持超类型的契约，见维基百科。
不完全是。反过来说：
那是一个集合
但是集合
通常，Collections由于存在“可选操作”而违反了Liskov替换原则，即变异方法可能无法用于特定实现。
但是，就类型安全而言，它是这样工作的：
假设Car是Vehicle的子类型，则为集合
Collection<Car> c=…;
Car car=c.iterator().next();
哪个集合
Collection<Vehicle> c=…;
Vehicle v=…;
c.add(v);
哪个集合
-
在创建我的班级结构时，我努力坚持利斯科夫替代原则。我想在Day类中存储一组日历项。需要有几种不同类型的日历项，例如： 任命项目 备注项目 轮换项目 它们都共享一些抽象基类CalendarItem中的常见功能： 但例如RotaItem有一些额外的功能： 其他类也添加了自己的逻辑等。 我有一组CalendarBaseItem用于我的日课： 但在回顾这一点时，我可以看到我正在打破LSP原则，因为我必须检
-
我发现很难理解这个概念。我脑子里有几个问题。我试着在网上查询，但是没有太多的资源。 子类是否需要在其整个生命周期中保持其独特性？ 我很确定LSP定义了超级类和子类之间的契约，如果我错了，请纠正我。 如果一个给定的函数使用某个对象，你能用它的一个子类替换这个对象而不破坏它的执行吗？ 如果有一个类型为超类的变量，程序是否仍然有效。如果我将该超类或任何子类的实例放入该变量中。 如果这没有道理，我很抱歉。
-
不幸的是，由于Liskov替换原则，Java中的子类在接受什么方法参数方面不可能比基类更有限制性，所以Java也允许一些永远不可能为真的无谓比较（并可能导致非常微妙的bug）： 另一个不幸的副作用是，正如Josh Bloch很久以前在《Effective Java》中指出的那样，在存在子类型的情况下，基本不可能按照其契约正确实现方法（如果在子类中引入额外的字段，实现将违反契约的对称性和/或传递性要
-
问题内容： 假设class 扩展class 。我碰巧知道 只 包含的实例。有什么方法可以将转换为吗？ 看来我唯一的选择是遍历集合，一次转换一个元素，创建一个新集合。鉴于类型擦除使得这在运行时完全不必要，这似乎完全浪费了资源。 问题答案： 您可以通过无类型的List界面进行强制转换：
-
LSP定义指出，如果S是T的子类型，则程序中T类型的对象可以替换为S类型的对象，而不改变该程序的任何期望属性。 子类型中的前提条件不能加强 例如，我有下面的类，这是违反（在子类型中不能加强前提条件）。我正试图把我的头绕在这上面，请有人提供一个好的例子来理解它。
-
我试图通过反复阅读维基百科条目来确定我对上述原则的理解。 撇开仍然让我悲伤的协变和逆变的概念不谈，wikipedia还提到超类型的不变量必须保留在子类型和历史约束或历史规则中。基于最后两个概念，我提出了一个小例子： 所以我的问题是：基于上述两个概念，我用这个例子是否违反了原则？若否，原因为何？ 事先非常感谢。