31–40 of 72 posts
Earlier quoted context omitted.
A struct is an object. Even a plain integer is an object, considering the referred article was talking about C++. (Yes, you cannot inherit all kinds of objects – but you definitely can inherit any kind of struct, POD or not.)
Well, if everything is an object, I guess everything is an object. Usually when people are talking about OO objects they mean data+behaviour.
Everyone keeps looking for the silver bullet, but ends up with answers that are simple, easy, and wrong.
If there is a bullet at all I think it is accepting that software architecture is made up of all these things + tools that give lots of extra information easily + interactivity and small iteration times.
I think when most people are being overwhelmed with complexity they want a silver bullet so badly they will believe that there is one against all evidence to the contrary.
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 ob…
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.
Another good article expressing a similar opinion which some might not have seen http://blog.codinghorror.com/your-code-oop-or-poo/
What baffles me about OOP is that massive aspects of how to use it have changed, and that change happened after it gained popularity as a good technique. How could it have become popular when people were doing it wrong? The article mentions inheritance, but there's also heavy vs light classes. When I was taught OOP, an object knew how to do all the things to itself. It could draw itself on the screen, modify itself,…
GOTO was fine, until it wasn't. Then we had structured programming and things were better.
Every language and methodology has had its pros and cons, and in general the trend has been towards "better" (by some dimension in a large, multi-dimensional space) languages and methods.
Heavy classes were an improvement over what existed before them, not because they were heavy classes, but because what was before them was still (often) unstructured code.
Light classes, moving things up a level so that, for instance, your graphical object doesn't draw itself, but instead knows enough to inform the drawing class how to draw it, is better in one particular regard: same object can be rendered in any system by updating the layer above it. So instead of updating 100 drawn objects, you now update 1 drawing object.
That doesn't make heavy classes "wrong", they were fine at their time (probably more performant, and almost certainly an improvement in some ways over what existed before them). But light classes with some degree of abstraction is often better (too much is still a problem, damn you ). Better, in this case: shorter code, fewer "moving" parts, easier to reason about, easier to manipulate. It is potentially less performant (depending on language and design choices), but that's not a guarantee.
I've encountered this code a lot in C, and every time I thought that this style of > stuff_do_something(stuff, some_parameter) _is_ OOP and identical to > stuff.do_something(some_parameter) , although in language without support for OOP (of course, you can hack OOP on top of C with preprocessors and stuff, but let's pretend we forgot about that embarrassing abominations). And every time I saw that I wished that I cou…
Exactly. OOP is: a) A code naming/organisational issue b) Some formalisation of structure, so that developers can specify what is/isn't allowed in their code. Both of thise have advantages and disadvantages, and the structure can be over-formalised and made too complex. But this doesn't make OOP bad. It makes bad design bad.
I've been saying this for years. Historically, yes, OOP has its own roots. But for all effects and purposes, C++ with headers controlling visibility is the grandfather of OOP. If you got that, then you've got OOP basics. (And, as the author points out, 90% of what you'll ever need) There's another way of "going beyond OOP" that bears some thought, and that's growing a program by incrementally adding functions, then g…
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 ob…
> 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 ov…
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.
Earlier quoted context omitted.
> 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 ov…
Let'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.
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.