14 ms·
I think of subtype polymorphism and dynamic dispatch as two different things, but maybe I'm misunderstanding something here. Subtyping/inheritance is sometimes
by dimal 3y ago
I think of subtype polymorphism and dynamic dispatch as two different things, but maybe I'm misunderstanding something here.
Subtyping/inheritance is sometimes convenient, but inheritance tends to be a constrictive way to reuse code that increases cognitive load. If B is a subtype of A, now, not only are the data of B coupled to the behavior of A, but the data or behavior of B _may or may not_ be coupled to A depending on whether B overrides A. More coupling. More cognitive load. And if you change A, you have to be careful that you don't break B. Then if you have C that's a subtype of B, then the cognitive load and possibility of unexpected breakage gets even higher. Ugh. No. I'm a simple-minded person. I don't want to think about stuff like that.
I see dynamic dispatch simply as a form of delegation, which can easily be accomplished functionally.
So, ultimately, again, I see these benefits as being _convenient_ but not _necessary_. And since all design decisions are trade-offs, I look at the downsides of the coupling and find that the trade-offs are simply not worth it.
- tomstuart 3y agoI don’t think you’re misunderstanding anything, but to clarify, I’m talking about a more general notion of subtyping (e.g. structural, “duck typing” etc), not necessarily inheritance. Instances of A and B can (in Smalltalk parlance) respond to the same set of messages, and therefore be substitutable for each other, without having any inheritance relationship. In that case there’s no coupling of implementation, only the flexibility of being able to swap out an A instance for a B instance without its collaborators being any the wiser.
- UncleMeat 3y agoSubtyping and inheritance are two entirely different concepts. You can have subtyping without inheritance and inheritance without subtyping.