Liskov替换原则4问题
我发现很难理解这个概念。我脑子里有几个问题。我试着在网上查询，但是没有太多的资源。
子类是否需要在其整个生命周期中保持其独特性？
我很确定LSP定义了超级类和子类之间的契约，如果我错了，请纠正我。
如果一个给定的函数使用某个对象，你能用它的一个子类替换这个对象而不破坏它的执行吗？
如果有一个类型为超类的变量，程序是否仍然有效。如果我将该超类或任何子类的实例放入该变量中。
如果这没有道理，我很抱歉。关于LSP，这4个问题困扰着我。
非常感谢你
共有1个答案
LSP：如果S是T的子类，那么S的每个实例都是T的实例。
这是真的，但它有影响。
我不知道你所说的子类“保持其独特性”是什么意思。
LSP确实意味着子类实例必须遵守超类契约，但它实际上是关于在其他契约中使用s或T时的含义。
例如，如果您编写了一个函数Number add（Number a，Number b），该函数应该添加两个数字，那么LSP表示，这实际上意味着它可以将Number的任何实例添加到Number的任何其他实例中，其中包括任何子类的实例。LSP说这个函数在其他情况下是不正确的，因为它所知道的关于Number的每个实例对于整数、浮点数、大小数等都是不正确的，因为这些都是Number的实例。
如果一个给定的函数使用某个对象，你能用它的一个子类替换这个对象而不破坏它的执行吗？
如果这是一个参数，而您不能，那么函数不正确，或者子类不正确。
如果有一个类型为超类的变量，程序还能工作吗？如果我把一个超级类或任何子类的实例放入变量中
不一定。仅仅因为变量的类型是整数，这并不意味着您可以任意将其设置为625并期望程序继续工作。code>是一个T
-
每个类都直接或间接地继承自类。 类有一个重要的方法，最常被重写：。 问题是：对于类，重写此方法是否会违反Liskov替换原则？ 我举个例子。 显然，如果我用替换，系统的行为就会改变。
-
在创建我的班级结构时，我努力坚持利斯科夫替代原则。我想在Day类中存储一组日历项。需要有几种不同类型的日历项，例如： 任命项目 备注项目 轮换项目 它们都共享一些抽象基类CalendarItem中的常见功能： 但例如RotaItem有一些额外的功能： 其他类也添加了自己的逻辑等。 我有一组CalendarBaseItem用于我的日课： 但在回顾这一点时，我可以看到我正在打破LSP原则，因为我必须检
-
不幸的是，由于Liskov替换原则，Java中的子类在接受什么方法参数方面不可能比基类更有限制性，所以Java也允许一些永远不可能为真的无谓比较（并可能导致非常微妙的bug）： 另一个不幸的副作用是，正如Josh Bloch很久以前在《Effective Java》中指出的那样，在存在子类型的情况下，基本不可能按照其契约正确实现方法（如果在子类中引入额外的字段，实现将违反契约的对称性和/或传递性要
-
我是OOP的新手。最近我读到了关于Liskov替换原理的文章。 在下面给出的代码中，Square类继承Give_区域。假设Square类与Square相关（比如有效性检查）。Give_Area给出正方形的面积（4个顶点位于圆的周长上）和圆的面积。所以，如果给我一个半径，我必须打印圆和正方形的面积（由放置在圆周长上的顶点组成）。为了得到圆的面积，我使用了一个参数。但在求平方面积时没有参数。因此，我在
-
Java不允许
-
问题内容： 我的情况与Code Complete中Steve McConnell 提到的情况非常相似。我唯一的问题是基于车辆，而三轮车恰好是根据法律，属于汽车。到目前为止，汽车只有四个轮子。无论如何，我的域都不必要地复杂，因此很容易遵循下面的cats示例。 对重写例程并且在派生例程中不执行任何操作的类要保持怀疑。这通常表明基类的设计存在错误。例如，假设您有一个Cat类和一个例程Scratch（），