This is just a bizarre, bizarre article. The author's point seems to hinge on the posit that inheritance is bad because... it means you have to open other files to understand the inner workings of...
This is just a bizarre, bizarre article. The author's point seems to hinge on the posit that inheritance is bad because... it means you have to open other files to understand the inner workings of code? I mean, yes, that's kind of the point. Good libraries and frameworks will abstract the need to understand superclasses—we put our code in different files to separate concerns and improve maintainability and readability, and yeah, sure, inheritance can be brittle and hard to scale with if not used properly—something that isn't really addressed in the article. But the same problem the author complains about apply to inheritance's brother, composition, too.
Everything in moderation. Perhaps the phrase "considered harmful" should be considered harmful—because the moment I see that suffix appended to article titles, I'm instantly at least 50% more skeptical of the claims therein!
In my experience, if you have more than two levels of inheritance in code that you didn't write yourself, it gets hard to find all the methods that might be called from a call site without an IDE....
In my experience, if you have more than two levels of inheritance in code that you didn't write yourself, it gets hard to find all the methods that might be called from a call site without an IDE. And if your class is part of a public API then it gets worse; it can be quite difficult to refactor without breaking something.
A specific problem with inheritance, not seen with composition, is that you can get accidental recursion due to overridden methods, when it's not clear whether you are calling up or down in the inheritance tree. (It can also happen with callbacks, but they are typically used more carefully.)
I didn't miss inheritance when I started using Go and I think Go's authors made a good choice not to include it. (Go has something that's almost the same called embedding but it's less of a problem.) But I still use it, in moderation, in languages that have it. You don't want to go against the flow too much.
A less extreme version of this opinion might be prefer composition to inheritance.
I don’t know if the author is right, I’m just a learner, but my semester with Java was nightmarish. To me Java is like an infinite Russian doll. I’m certain it’s a very useful Russian doll, but...
I don’t know if the author is right, I’m just a learner, but my semester with Java was nightmarish. To me Java is like an infinite Russian doll. I’m certain it’s a very useful Russian doll, but puzzling nonetheless. And extremely bureaucratic.
The language I have more experience with is Emacs Lisp, with Python as a close second. I like Elisp because it’s transparent and reasonably regular. I can do shit even if I don’t know shit. All the pieces are there for me to see. If I wanna use a function I just put the function there. If something looks like it will work, there’s a great chance that it will. I may be the dumbest lisper in history – my lisp “programming” technique is basically a mix of stubbornness and pattern recognition. Not even Python let me do that.
I actually don't really understand your characterization of Java. I think the only time I ever actually used inheritance in Java was when they made us use it for class, and even during the...
I actually don't really understand your characterization of Java. I think the only time I ever actually used inheritance in Java was when they made us use it for class, and even during the inheritance lectures they straight up told us "Try to avoid using inheritance when you can".
You will probably see it used a lot more outside of class. Unfortunately, although avoiding inheritance is conventional wisdom, in practice it's used heavily in large Java projects. The Android...
You will probably see it used a lot more outside of class. Unfortunately, although avoiding inheritance is conventional wisdom, in practice it's used heavily in large Java projects. The Android API's are a good example. Here is RadioButton, already six levels deep. It's not uncommon to be ten levels deep or more.
GUI frameworks in particular often heavily exploit inheritance trees, because the logical relationships between components generally want to have that structure. It's one of the few domains where...
GUI frameworks in particular often heavily exploit inheritance trees, because the logical relationships between components generally want to have that structure. It's one of the few domains where inheritance is actually considered the best practice.
Your general point—that inheritance is mostly overused in languages that provide it—still holds, of course.
There is Considered Harmful considered harmful I'm not very well learned on the matter but from my understanding inheritance is dangerous because it messes with encapsulation in weird ways....
I'm not very well learned on the matter but from my understanding inheritance is dangerous because it messes with encapsulation in weird ways. Imagine a class Parent that implements a visible / public method doStuff(). This method relies on less visible methods / attributes to operate (imagine a setup method, or a flag attribute). If you create a Child class and override one of these inner methods you are modifying doStuff() in ways that are only obvious if you have full understanding of the inner workings of Parent. Now imagine Parent is part of the public API of a library you download that might or might not have sources available...
If you mix functionality using composition, Component.doStuff method would be isolated from any changes in Child classes. You can still modify Component.setup or Component.flag, but as parameters to doStuff() or during Component instantiation.
It is messy to explain because composition and inheritance are mostly equally expressive to me, but I think composition makes APIs be more explicit about its moving parts.
Author here! It's unfortunate that you chose to bash on easiest part of the post. I think it should be pretty clear that the main point is that you have to go back and forth between just two...
Author here!
It's unfortunate that you chose to bash on easiest part of the post. I think it should be pretty clear that the main point is that you have to go back and forth between just two classes! What if there was 5 of them? How would you know which class to look at? When you see a function call, you know for sure which function was called, there is no doubt. But inheritance convolutes everything!
In case I made you too skeptical by choosing a name like this, you might be interested to look at this thread at lobsters, where others have contributed more than I ever hoped for.
Okay, that's just me reaction to 'bizarre, bizarre' part. :-) But honestly, I'm not against traveling through files. I'm against non-deterministic routes!
Okay, that's just me reaction to 'bizarre, bizarre' part. :-) But honestly, I'm not against traveling through files. I'm against non-deterministic routes!
This is just a bizarre, bizarre article. The author's point seems to hinge on the posit that inheritance is bad because... it means you have to open other files to understand the inner workings of code? I mean, yes, that's kind of the point. Good libraries and frameworks will abstract the need to understand superclasses—we put our code in different files to separate concerns and improve maintainability and readability, and yeah, sure, inheritance can be brittle and hard to scale with if not used properly—something that isn't really addressed in the article. But the same problem the author complains about apply to inheritance's brother, composition, too.
Everything in moderation. Perhaps the phrase "considered harmful" should be considered harmful—because the moment I see that suffix appended to article titles, I'm instantly at least 50% more skeptical of the claims therein!
In my experience, if you have more than two levels of inheritance in code that you didn't write yourself, it gets hard to find all the methods that might be called from a call site without an IDE. And if your class is part of a public API then it gets worse; it can be quite difficult to refactor without breaking something.
A specific problem with inheritance, not seen with composition, is that you can get accidental recursion due to overridden methods, when it's not clear whether you are calling up or down in the inheritance tree. (It can also happen with callbacks, but they are typically used more carefully.)
I didn't miss inheritance when I started using Go and I think Go's authors made a good choice not to include it. (Go has something that's almost the same called embedding but it's less of a problem.) But I still use it, in moderation, in languages that have it. You don't want to go against the flow too much.
A less extreme version of this opinion might be prefer composition to inheritance.
I don’t know if the author is right, I’m just a learner, but my semester with Java was nightmarish. To me Java is like an infinite Russian doll. I’m certain it’s a very useful Russian doll, but puzzling nonetheless. And extremely bureaucratic.
The language I have more experience with is Emacs Lisp, with Python as a close second. I like Elisp because it’s transparent and reasonably regular. I can do shit even if I don’t know shit. All the pieces are there for me to see. If I wanna use a function I just put the function there. If something looks like it will work, there’s a great chance that it will. I may be the dumbest lisper in history – my lisp “programming” technique is basically a mix of stubbornness and pattern recognition. Not even Python let me do that.
I actually don't really understand your characterization of Java. I think the only time I ever actually used inheritance in Java was when they made us use it for class, and even during the inheritance lectures they straight up told us "Try to avoid using inheritance when you can".
You will probably see it used a lot more outside of class. Unfortunately, although avoiding inheritance is conventional wisdom, in practice it's used heavily in large Java projects. The Android API's are a good example. Here is RadioButton, already six levels deep. It's not uncommon to be ten levels deep or more.
GUI frameworks in particular often heavily exploit inheritance trees, because the logical relationships between components generally want to have that structure. It's one of the few domains where inheritance is actually considered the best practice.
Your general point—that inheritance is mostly overused in languages that provide it—still holds, of course.
Yeah. I’m not a super fan of OOP right now, but I know it’s unavoidable.
I’m actually not talking just about inheritance, but about everything a OOP language requires.
There is Considered Harmful considered harmful
I'm not very well learned on the matter but from my understanding inheritance is dangerous because it messes with encapsulation in weird ways. Imagine a class Parent that implements a visible / public method doStuff(). This method relies on less visible methods / attributes to operate (imagine a setup method, or a flag attribute). If you create a Child class and override one of these inner methods you are modifying doStuff() in ways that are only obvious if you have full understanding of the inner workings of Parent. Now imagine Parent is part of the public API of a library you download that might or might not have sources available...
If you mix functionality using composition, Component.doStuff method would be isolated from any changes in Child classes. You can still modify Component.setup or Component.flag, but as parameters to doStuff() or during Component instantiation.
It is messy to explain because composition and inheritance are mostly equally expressive to me, but I think composition makes APIs be more explicit about its moving parts.
Author here!
It's unfortunate that you chose to bash on easiest part of the post. I think it should be pretty clear that the main point is that you have to go back and forth between just two classes! What if there was 5 of them? How would you know which class to look at? When you see a function call, you know for sure which function was called, there is no doubt. But inheritance convolutes everything!
In case I made you too skeptical by choosing a name like this, you might be interested to look at this thread at lobsters, where others have contributed more than I ever hoped for.
I don't think I'm bashing, just disagreeing with that statement :)
Okay, that's just me reaction to 'bizarre, bizarre' part. :-) But honestly, I'm not against traveling through files. I'm against non-deterministic routes!