Timeline for How is defining that a method can be overridden a stronger commitment than defining that a method can be called?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 31, 2015 at 23:04 | comment | added | eigensheep | If you don't permit your class to be inherited from, people using your code will use composition instead. This comes with all the same possibilities of someone forgetting to cleanup. You don't gain anything in this regard by avoiding inheritance. | |
| Dec 7, 2015 at 9:14 | comment | added | Sebb | @Doval I'm not saying everything should be virtual by default. My point is that a few key functions/classes marked as virtual will make some users lives far easier and should not be disallowed just because "a user may screw it up". | |
| Dec 6, 2015 at 20:35 | comment | added | AaronLS | Considering protected access level of fields the overridden method can access, opens more possibilities for derived classes to invalidate assumptions the base class made. | |
| Dec 6, 2015 at 20:15 | audit | First posts | |||
| Dec 7, 2015 at 23:13 | |||||
| Dec 6, 2015 at 6:41 | comment | added | Kevin Krumwiede | @Doval Indeed. Which is why it's a travesty that inheritance is lesson number one in just about every introductory OOP book and class. | |
| Dec 5, 2015 at 17:46 | comment | added | Doval | @Sebb There's also the issue that single (class) inheritance doesn't compose. I've got some functionality in class A and some other functionality in class B, but I can't inherit from both A and B. All in all inheritance makes a very poor default. It's something you should only reach for only after careful consideration. | |
| Dec 5, 2015 at 17:41 | comment | added | Doval | @Sebb You can't just blindly allow every method to be overridable. For every virtual method the circumstances under which it'll be called (which methods call it, which methods don't, and what the state of the object will be at the time) become part of the public API. If every method is virtual you must maintain these conditions for every single pair of methods (e.g. foo can't suddenly start calling bar, or stop calling baz) See this paper for details. You must pick which methods should be virtual and nail down the rest. | |
| Dec 5, 2015 at 11:41 | comment | added | David Arno | @svick, you are of course entitled to that opinion. In my view, this is just one of a great many arguments against ever opting for inheritance to anything. To that extent, I never use it unless I'm working with an API that forces me to. I even go as far as marking all my public classes as final/sealed so they cannot be inherited from. A step too far in the minds of some, but the nature conclusion to reach regarding inheritance in my view. | |
| Dec 5, 2015 at 9:07 | comment | added | Pieter B | You could easily turn that argument around into: the first coder makes a cleanup argument, but makes mistakes and doesn't clean everything up. The second coder overrides the cleanup method and does a good job, and coder #3 uses the class and doesn't have any resource leaks even though coder #1 made a mess of it. | |
| Dec 4, 2015 at 20:40 | comment | added | Sebb | While this sounds like a good point I can't really see how "a user may add his own buggy code" is an argument. Enabling inheritance allows users to add lacking functionality without loosing updateability, a measure which can prevent and fix bugs. If an users code atop of your API is broken it its not an API flaw. | |
| Dec 4, 2015 at 20:23 | comment | added | JAB | A solution to the cleanup issue would be to have a private cleanup that at the end calls a user-specifiable cleanup. | |
| Dec 4, 2015 at 19:35 | comment | added | svick | @DavidArno I don't think it's an argument against inheritance. I think it's an arguments against "make everything overridable by default". Inheritance is not dangerous by itself, using it without thought is. | |
| Dec 4, 2015 at 17:38 | comment | added | enderland | This problem is even more interesting (or terrifying?) if you consider not just a single inheritance, but a chain of them. Or a complicated mess of inheritances - at least with a linear chain it's "clear" what the potential minefield is. | |
| Dec 4, 2015 at 16:34 | comment | added | David Arno | This is possibly the best argument against inheritance that I've ever read. Of all the reasons against it that I've encountered, I've never come across these two arguments before (coupling and breaking functionality through overriding), yet both are very powerful arguments against inheritance. | |
| S Dec 4, 2015 at 16:15 | history | suggested | Null | CC BY-SA 3.0 |
fixed spelling; added code formatting
|
| Dec 4, 2015 at 16:09 | review | Suggested edits | |||
| S Dec 4, 2015 at 16:15 | |||||
| Dec 4, 2015 at 15:54 | history | edited | Kilian Foth | CC BY-SA 3.0 |
fix paragraphs
|
| Dec 4, 2015 at 15:51 | vote | accept | q126y | ||
| Dec 4, 2015 at 15:40 | history | answered | Kilian Foth | CC BY-SA 3.0 |