Timeline for What can go wrong if the Liskov substitution principle is violated?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2016 at 12:30 | comment | added | sara |
it WOULD be reasonable to describe the Close() method as something that MIGHT fail depending on the state of the runtime type though right? it's one thing if the interface contract says "Close() always closes the task", but is it really so bad to say "Close() closes the task if it is permitted to do so at the moment"?
|
|
| Jun 4, 2015 at 20:32 | comment | added | Andres F. | @user949300 I cannot give you an example of convoluted production code and don't have the time to distill it to its essentials. But Jimmy Hoffa's last comment hit the mark: it's not enough for software to "work", the costs of maintaining and refactoring it have to be taking into account. Otherwise, what's the point of having generics in Java, if collections of Objects work just as well? | |
| Jun 4, 2015 at 4:04 | comment | added | user949300 | Jimmy and Andres, please give a real world example, from your work, where not following LSP has hurt you. Sounds like you should have a good example from the well known horrible Java Collections. If it is a good example I will upvote. | |
| Jun 4, 2015 at 0:38 | comment | added | Jimmy Hoffa | @user949300 The success of any piece of software to accomplish it's job is no measure of it's quality, long-term, or short-term costs. Design principles are attempts at bringing about guidelines to reduce long-term costs of software, not to make software "work". People can follow all the principles they want while still failing to implement a working solution, or follow none and implement a working solution. Though java collections may work for many people, that does not mean the cost to work with them in the long run is as cheap as it could be. | |
| Jun 3, 2015 at 23:22 | comment | added | Andres F. | @user949300 The Java Collections is a terrible counterexample, because they are known to have multiple historical problems. You can work around them, but it'd be better if they weren't there. Remember, at one time Java Collections didn't even support generics, and people still managed to write useful programs without them. Does this make generics useless, or "fairly academic"? :) | |
| Jun 3, 2015 at 23:19 | comment | added | Andres F. | @user949300 This is not "fairly academic". If subclassing breaks existing methods which accept the superclass, this introduces a maintenance nightmare. You cannot introduce unit test to cover for every deviation a subclass can make, and you cannot predict them. Like this answer states, this problem can be seen as a case of tight coupling, which is a very serious and real-world software engineering concern! | |
| Jun 3, 2015 at 21:10 | comment | added | user949300 |
While I understand and appreciate this answer, if this is the worst than can happen with a violation of LSP, then I'm with @Paul T Davies, the LSP is fairly "academic" and of relatively little importance in the real world. A good unit test (or in many cases the compiler) would catch that exception and lead to something like the canClose() option in the original question. I mean, Java Collection's somewhat infamous optional methods violate LSP in this manner and millions of people make it work for them.
|
|
| Oct 18, 2012 at 14:52 | comment | added | Jimmy Hoffa | @Phil Yep; this is the definition of tight coupling: Changing one thing causes changes to other things. A loosely coupled class can have it's implementation changed without requiring you to change code outside of it. This is why contracts are good, they guide you in how not to require changes to your object's consumers: Meet the contract and the consumers will need no modification, thus loose coupling is achieved. When your consumers need to code to your implementation rather than your contract this is tight coupling, and required when violating LSP. | |
| Oct 18, 2012 at 14:01 | comment | added | Phil | So in other words, the more you violate the Liskov Substitution principle, the harder it is to maintain your code because you have to make changes in many places rather than just one place. | |
| Oct 18, 2012 at 5:01 | vote | accept | Geek | ||
| Oct 17, 2012 at 19:40 | comment | added | Chewy Gumball | No. This is for when a child class is referenced as if it were a type of the parent class, in which case members which aren't declared in the parent class are inaccessible. | |
| Oct 17, 2012 at 19:39 | comment | added | Emilio Garavaglia | @Songo: Not necessarily: it can, but those methods are "unreachable" from a base pointer (or reference or variable or whatever the language you use calls it) and you need some run-time type information to query what type the object has before you can call those functions. But this is a matter that is strongly related to languages syntax and semantics. | |
| Oct 17, 2012 at 19:32 | comment | added | Songo | Does that mean that a child class can't have his own public methods that aren't declared in the parent class? | |
| Oct 17, 2012 at 15:12 | history | answered | Jimmy Hoffa | CC BY-SA 3.0 |