爲什麼InflaterInputStream＃available（）違反了Liskov替換原則？

-4

從Android Reference：爲什麼InflaterInputStream＃available（）違反了Liskov替換原則？

雖然與RI一致，這種行爲是可以（不一致），並違反了里氏替換原則。不應該使用這種方法。

爲什麼以及該方法如何違反該原則？

作爲一個側面問題，RI代表什麼？

來源

2013-05-17 kolistivra

與數據庫有關的RI意味着參照完整性。一旦你瞭解了RI和LSP，你的問題就會回答自己。 – 323go

由於這與數據庫無關，我認爲在這種情況下的RI是指參考實現。 –

@ 323go對SO的本質*任何*問題都可以得到同樣的推理。關於C++/Java/C的問題？只要閱讀規範，你就可以走了。我相信Android引用特別批評Java API的事實值得一提。 – kolistivra

從API文檔判斷，這種過度使用方法的執行不能提供與the superclass version相同的保證。

超類，InputStream，提供與問候以下保證阻塞：

返回的估計數目可以讀取或跳過而不阻斷更多的輸入字節的。

請注意，此方法提供了這樣一個弱保證，它不是在實踐中非常有用。

首先，保證是「不阻塞更多的投入」，而不是「不堵」：讀仍可能阻塞等待I/O，以完成 - 保證僅僅是它不會有等待無限期地寫入數據。此方法的結果應該不會被用作在不應被阻止的線程上執行I/O的許可證。

然而，子類，InflaterInputStream，不提供相同的保證：

的1的結果並不能保證進一步字節可以被返回，具有或不具有阻塞。

因此，您無法使用代替正常InputStream一個InflaterInputStream沒有考慮封鎖行爲的差異。

來源

2013-05-17 14:27:30

爲什麼InflaterInputStream＃available（）違反了Liskov替換原則？

回答

相關問題