错误的接口实现是否违反Liskov替换原则？

Question

让我们考虑以下接口实现：

Comparator<String> stringComparator = (o1, o2) -> 0;

是否违反Liskov替代原则？

Answer 1

在这个特定情况下，没有。您的示例Comparator只是说所有字符串都相等。这满足了Comparator的合同（参见javadoc），更广泛地说它满足Liskov替代性原则（LSP）。

（这个Comparator没有用 ¹ ，可能是错误/错误，但LSP没有被违反。）

在更一般的情况下，一个不满足Comparator合同的Comparator实现在技术上违反了LSP。但你也可以说它已经坏了。你修复它主要因为它被破坏/赢得了正常工作......不是因为某些设计原则。

更一般地说，并非所有LSP违规的例子都是破坏的代码。一个例子是IdentityHashMap，在测试密钥是否相同时（故意和有用）违反了Map的合同，而不是使用equals()。 （它使用==代替。正确地说，考虑到类的目的。）

LSP违规可能导致意外行为，但并非所有意外都是错误。

^{1 - 我无法想到使用这种比较器是明智的。不是TreeMap。没有排序......}

Answer 2

此比较器实现完全有效的总订单。

检查公理：

• 对于所有a，b：如果a <= b和b <= a则a = b是微不足道的（前提无所谓，后果始终为真）
• 传递性是微不足道的，因为a <= b适用于所有a，b
• 总体性是微不足道的：对于所有a，b，它同时包含a <= b和b <= a。

所以，即使它与Liskov的替换原则有关，它仍然只是Comparator的完全有效的实现。