Timeline for Liskov substitution principle with abstract parent class
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 7, 2014 at 6:34 | comment | added | Doc Brown | @mfjgates: I think you have the correct thing in mind, but how you describe it, it can be too easily misunderstood. If you add the wrong "additional feature", LSP can be violated either. For example, adding some error checking (which might cause an exception) to a method which was by contract exception-free can make code using those objects unintentionally not working. | |
| Jun 6, 2014 at 17:36 | comment | added | mjfgates | @Songo: Liskov means that that what works on the superclass should work on subclasses, not that things that don't work on the superclass have to also fail on subclasses. Subclasses implement additional features all the time, that's one of the main reasons we bother to write them. | |
| Jun 6, 2014 at 17:00 | comment | added | Doc Brown | @Songo: the focus is on "works correctly with all subclasses". So its not primarily about substitutibility of the superclass with a subclass, its about substitutibility of one subclass with another subclass. | |
| Jun 6, 2014 at 16:50 | comment | added | Songo | Thanks for the answer. About ur point "code that works correctly with the superclass should also work correctly with all subclasses", since we can't instantiate an abstract class doesn't that make it impossible to substitute with a child? | |
| Jun 6, 2014 at 16:42 | history | answered | psr | CC BY-SA 3.0 |