Timeline for What can go wrong if the Liskov substitution principle is violated?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 19, 2018 at 7:22 | comment | added | Kaz Dragon | @maverick This is really difficult to do, because any example would give the result, "well that's obviously wrong!" and that's kind of the point. LSP is why those things are wrong. Consider a filesystem that hosts any file type that has associated open/close/read/write operations. A particular file type implementation requires a new function init to be called after open, before reading or writing, otherwise it fails to read or write. This fails LSP because any code written for the basic file types will not work with the new function: the new file type is not substitutable. | |
| Jul 17, 2018 at 16:39 | comment | added | darKnight | @KazDragon I see your point and understand its theoretical argument, but can you list a real world example where not following LSP would actually be surprising and more importantly, cause unexpected behaviour or a bug? Even in above example, the result of passing circle instead of ellipse to some_function should not surprise the user as he is trying to cause a fundamentally incorrect behavior on circle by only setting its alpha radius. I would argue that this is a flaw in implementation by the user rather than an unexpected behaviour by the API (as it's maintaining the integrity of the circle) | |
| Jul 17, 2018 at 14:45 | comment | added | Kaz Dragon | @maverick I believe you have read the relationship I described backwards. The proposed is-a relationship is the other way around: a circle is an ellipse. Specifically, a circle is an ellipse where the alpha and beta radii are identical. And so, the expectation might be that any function expecting an ellipse as a parameter could equally take a circle. Consider calculate_area(Ellipse). Passing a circle to that would yield the same result. But the problem is that the behaviour of the mutation functions of Ellipse are not substitutable for those in Circle. | |
| Jul 16, 2018 at 6:00 | comment | added | darKnight | @KazDragon: Why would anyone substitute an ellipse with a circle object when we know that an ellipse IS NOT A circle? If someone does that, they do not have a correct understanding of the entities they are trying to model. But by allowing this substitution, aren't we encouraging loose understanding of the underlying system that we are trying to model in our software, and thus creating bad software in effect? | |
| Oct 25, 2012 at 8:48 | comment | added | Kaz Dragon | @Giorgio Yes, I should have mentioned that this problem only occurs with mutable objects. | |
| Oct 24, 2012 at 15:25 | comment | added | Giorgio | In a purely functional world (with immutable objects), the method set_alpha_radius(d) would have return type ellipse (both in the ellipse and in the circle class). | |
| Oct 24, 2012 at 15:23 | comment | added | Giorgio | I think you can run into trouble if you use mutable objects. A circle is also an ellipse. But if you replace an ellipse which is also a circle with another ellipse (which is what you are doing by using a setter method) there is no guarantee that the new ellipse will also be a circle (circles are a proper subset of ellipses). | |
| Oct 19, 2012 at 7:30 | history | edited | Kaz Dragon | CC BY-SA 3.0 |
added 39 characters in body
|
| Oct 18, 2012 at 12:59 | history | answered | Kaz Dragon | CC BY-SA 3.0 |