Oop 利斯科夫'；s替代原则与开放/封闭原则冲突？

今天有人问我Liskov的替代原则与开放/封闭原则有何冲突，有什么想法吗

---

这是否与使用OC原则扩展父类有关，然后无法使用Liskov的原则替代父类？

假设您有一个库，其中包含一个具有某些功能的类a，并且您希望更改该类（其一部分）的行为

如果您希望遵守打开/关闭原则，则应创建一个子类，该子类派生自a，并且其行为不同（因为该原则禁止您更改a类）

如果您希望遵守Liskov原则，则不允许创建具有不同行为的子类，因此您应该更改原始类

这意味着在这种情况下不可能同时遵守这两个原则

示例

类“StorageController”有一个函数Store（），它将项目存储为XML文件。现在您想更改它，使其存储一个JSON文件

打开/关闭原则表示必须创建一个子类“JsonStorageController”，该子类重写此方法以存储json而不是xml。但是，这违反了Liskov原则，因为不能简单地用JsonStorageController替换StorageController

---

当然，还有一些解决方案不违反这些原则，例如重写基类并添加额外的方法“StoreToJson”，但是这些解决方案可能会违反其他原则，例如单一责任原则（给子类赋予两种不同的责任）

“如果你想遵守Liskov原则，就不允许创建具有不同行为的子类”这是对LSP的一种不寻常且过于严格的解释。请看你是对的，@kaya3，我在那里走了一条捷径。正如你链接中的答案所述，这取决于合同。在我的示例中，如果Store（）的合同如果是“将数据存储为XML文件”，我们就违反了LSP。但是，如果合同是“存储数据”，我们就可以……LSP和OCP之间没有冲突。否则的示例表明对一个或两个原则的理解不完整。当然，给定的代码可能违反这两个原则；但这是完全不同的这是一个很难在没有任何证据的情况下做出的陈述。