I’m not sure I could explain it well myself, but many years ago, back when I was still rather new to programming I just never understood it until one day I was working on something and it clicked.
Ok, I'll take the bait. If "literally all of you are doing it wrong", then why even try to define the "right" way to do OOP? Is OOP even a good thing? Or has it failed to live up to its promises?
(Insert FP fanboy platitude about how objects are a poor man's closures, or something along those lines)
One of the biggest issues with OOP I think is the lack of a unified understanding. I think there's value in trying to define a "right" way, if only so that when we are talking about OOP, we are talking about the same thing.
I think that definition would require a volume of text, so I'm not prepared to fully elaborate, but ultimately I think that the core issues lie in our approach. We tend to think like computers when programming, which leads to OOP being a morass of procedural code masquerading as objects. Effectively, we tend toward functional decomposition. Code is boxed up into related data and behavior, and we call these "objects". What we really should be doing is approaching object design as a function of behavioral affordances.
Object design then becomes a necessary, often overlooked, step.
Object design is the first hurdle. The second is in the actual implementation, wherein we traditionally treat our objects as "data" and "behavior upon that data". I can't tell you how many times I've cringed at seeing "Thing" and "ThingManager" in code.
OOP might not be a good thing. It definitely isn't a good thing when it is done poorly. Exposing an object's data, for instance, makes the entire paradigm worthless. The widespread acceptance of `public` data members completely ruins the usefulness of OOP.
That brings up implementation languages. Programming languages really want you to use them, and they make it easy to eschew good OOP principles in favor of ease of use. Accessibility features and syntactic sugar lead not only lead us away from the paradigm, but also confuse about what it actually is.
OOP's biggest strength, and one that most of the literature doesn't go into, is it's ability to lighten cognitive load. When an object works independently of its environment, it is easy to both learn and understand that object. But we sacrifice a huge chunk of this strength in the name of "getting the work done".
I believe that good OOP resembles FP in implementation. Not completely, but much more closely than the procedural landmines we're used to would have us believe. OOP just provides a lower barrier to entry in that it lends itself well to the usage of basic programming constructs and it more closely resembles how humans think, though that could also be argued.
There is no agreed definition of OO so what you are claiming is obviously wrong. But who cares? What we are doing with programming is solving problems. I don’t care if you are doing it “right” or not according to some arbitrary definition. But, having said all that, IMHO Erlang programmers are doing OO better than anybody else. And I am not an Erlang programmer.
I would actually love to hear/read about this more, especially the part where you compare others' misconceptions with what you think differently. I've been interested in how people get the "wrong" idea for a very long time and I like getting feedback from others on this matter.
Language is fuzzy. Every word you say is a theory that carries with it everything you know about a word.
"Red" may bring to mind the color. It may bring to mind anger. It may bring to mind a bull and a matador.
All of those things happen in your subconscious, and they affect your understanding in uniquely-local ways.
So the transfer of information through speech from my mind to yours may sound very direct, but your interpretation of what I am saying is different than my interpretation of what I'm saying in very subtle ways.
Because of this, there's a very good chance that I am either completely wrong because I have misinterpreted things, that I am wrong because you have different context than I do, or that I have done a poor job of explaining things because context exists locally (in my head) that you don't have.
About this topic in particular, it was hyperbole to say "you are all doing it wrong". What is more accurate to say is that "my understanding of OOP is different in implementation than what I'm used to seeing, and I believe that my understanding is more correct/beneficial than those implementations"
I think the question in 2021 is more "why would anyone use OOP at all, compared to other techniques, outside of a few niche use cases?" (though I agree OOP can be very useful in niche use cases where having lots of scattered state makes sense, such as when writing a UI component library)