Inheritance is evil, and must be destroyed: part 1(berniecode.com)
berniecode.com
Inheritance is evil, and must be destroyed: part 1
http://www.berniecode.com/writing/inheritance/
6 comments
one problem that i have with inheritance, especially several layers deep is that it hides code from the developer and it makes it hard to get an idea of what is going on. A sequence of calls needs to be traced across several class definitions. Sometimes inheritance makes sense as an abstraction mechanism but i think it's often overused, especially in Java
Only a problem if you are browsing your project with notepad.
The way the author uses the common implementation reminds me of Ruby mixins. One of the things that takes a bit of getting use to in Ruby is that classes aren't types, and object hierarchy is used to share implementation, rather than enforce type.
Inheritance is a useful tool. The article mentions the strategy pattern which, ironically, often requires inheritance to implement. So I feel like the author may have been burned and/or confused by inheritance, and following true nerd form has cast it aside completely.
Sometimes when you are using a framework, the productivity gained from inheritance cannot be ignored. I suppose this depends on the language and framework design, to a limited extent.
That said, I try to compose rather than inherit when possible, as it provides a more opaque implementation.
Sometimes when you are using a framework, the productivity gained from inheritance cannot be ignored. I suppose this depends on the language and framework design, to a limited extent.
That said, I try to compose rather than inherit when possible, as it provides a more opaque implementation.
> The article mentions the strategy pattern which, ironically, often requires inheritance to implement.
Not really. It only requires interface inheritance for statically-typed languages, which is not really inheritance, and no inheritance at all for duck-typed languages.
Not really. It only requires interface inheritance for statically-typed languages, which is not really inheritance, and no inheritance at all for duck-typed languages.
Compositing should always he used over inheritance where possible, in my opinion. However, claiming inheritance should never be used is a bit unrealistic. There are times when it is a useful and logical choice.
Very lucid description of one of the major pitfalls (cough) inherent with a strict OOP design structure where the problem domain and/or programming language does not facilitate its imposition.
I even use objects a lot less - prefering to pass around hashes until they've blossomed into fairly well defined types. To me, a class is a data structure that provides a namespace for the functions that manipulate it, and little more.
In any case, I think nearly empty classes with nothing but accessors have no use in dynamic languages (in static languages they provide at least code completion support.)
I also increasingly dislike local variables and if-statements (preferring case statements). I like my methods having flow, and if-statements and local variables break that flow, like a caesura in music.
What bothers me is that I don't know if this is my progress towards becoming a zen-like programmer, or just me being bored with the old way of doing things, and discovering a new fad. It seems there is no way to tell.