为什么 InflaterInputStream#available() 违反了里氏替换原则？ [关闭]答案

【问题标题】：Why does InflaterInputStream#available() violates Liskov Substitution Principle? [closed]为什么 InflaterInputStream#available() 违反了里氏替换原则？ [关闭]
【发布时间】：2013-05-17 13:58:32
【问题描述】：

来自Android Reference：

虽然与 RI 一致，但这种行为与 available()，并且违反了 Liskov 替换原则。这方法不应该使用。

这种方法为什么以及如何违反原则？

作为一个附带问题，RI 代表什么？

【问题讨论】：

RI 与数据库相关的意思是参照完整性。一旦您了解了 RI 和 LSP，您的问题就会得到解答。
由于这与数据库无关，我认为本例中的 RI 指的是参考实现。
@323go 对于关于 SO 的基本上 any 问题可以给出相同的推理。关于 C++/Java/C 的问题？只需阅读规范，您就可以开始了。我认为 Android 参考文献专门批评 Java API 的事实值得一问。
不，在这里的上下文中“不值得询问”。它促进了毫无意义的讨论。 SO 是问“如何”而不是“为什么”。请参阅常见问题解答，了解 SO 最适合哪种问题。
不仅我的问题是关于“如何”并且无法开始“毫无意义的讨论”，我也不同意这个网站不是“为什么”，如果你能我会很高兴在常见问题解答中指出这一点。哎呀，即使是 SO 的 the highest voted question 也以“为什么”开头！

标签： java android inflate deflate liskov-substitution-principle

【解决方案1】：

从 API 文档来看，这种重写方法的实现并不能提供与 the superclass version 相同的保证。

超类InputStream 提供以下关于阻塞的保证：

返回可以读取或跳过的估计字节数没有阻止更多输入。

请注意，此方法提供的保证很弱，因此不会在实践中非常有用。

首先，保证是“不阻塞更多输入”而不是比“无阻塞”：读取可能仍会阻塞等待 I/O 完成——保证只是它不必等待无限期地写入数据。这种方法的结果应该不得用作在不应执行的线程上执行 I/O 的许可证被屏蔽了。

但是，子类InflaterInputStream 不提供相同的保证：

结果为 1 并不能保证可以返回更多字节，有或没有阻塞。

因此，如果不考虑阻塞行为的差异，您就不能使用InflaterInputStream 代替普通的InputStream。

【讨论】：