5 ms·
I don't disagree with the author's sentiment about inheritance (or OOP in general), being used and taught wrongly, but I still think it's a necessary tool to ha
by sparkie 11y ago
I don't disagree with the author's sentiment about inheritance (or OOP in general), being used and taught wrongly, but I still think it's a necessary tool to have available.
Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler (reinterpret_cast. ie, undefined behaviour), or you need to break encapsulation to copy the fields over from one object to another.
Of course we could use an opaque pointer to our objects instead, but if your solution is to cast anything to (void*), where could that possibly go wrong?
OOP inheritance is pretty much doing that, but in a constrained, statically enforced way, which prevents programmers from making elementary mistakes or trying to make assumptions about the way hardware works.
Of course, the last example of the singleton works, but it also doesn't help to explain why we might use singletons in OOP. If we assume we have both a hardware mixer and a soft mixer which both have the set volume method, we wan't polymorphism so we can treat them equally. In the author's solution, we must treat each specially at the call site, which also violates our open/closed principle - we want to add new mixers without hacking (and breaking) the existing code.
Still, I pretty much agree that we should rethink the way these are taught. Perhaps every student should write his own OOP language before being let loose with it.
- l_dopa 11y agoYou're describing subtyping which, like modularity, does not require inheritance or really any other part of "OOP". I think that supports the article's point that C++, Java, etc. only support certain language features in an ad-hoc way tied to their object systems, making them, among other things, poor teaching languages.
- rlidwka 11y ago> Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler Why would you want to cast mixer to something else? What real-life task does it solve? > If we assume we have both a hardware mixer and a soft mixer which both have the set volume method, we wan't polymorphism so we can treat them equally. Polymorphism isn't OOP feature. You can have overloaded `mixer_set(struct, int)` without any OOP wizardry involved.
- Retric 11y agoLet's suppose you want labels, text boxes, and buttons on a form. Now you can do this without OOP or making a huge chunk of form code, but OOP is a natural fit. Especially if we may want to add pictures or video in the future.
- seivan 11y agoAre you saying all these outlets (labels, text box, buttons) are inheriting from a base FormObject that can be rendered? That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.
- Retric 11y agoSure, but routing get's complex in your solution. The point was OOP is a natural fit for collections of different types in some context ex:GUI, Simulation, etc. The classic OOP case is probably a MUD where OO code ends up being very straightforward. IMO, the problem is it works really well in so many contexts that people end up trying to use it everywhere.
- Jtsummers 11y agoOO in MUDs seemed so natural to me, I think, because they're closer to the actor model that OO was really designed for. Instead of "methods", many objects in MUDs (depending on the system, I used to know more when I was research writing a MUD engine in erlang), respond to messages in more of a smalltalk-style.
- seivan 11y agoRouting? I'm just saying that OOP is as much of a perfect fit to GUI that Entity Component Systems (composition) are.
- Retric 11y ago