The many "you're wrong if you believe that" made me remember the anecdote of Alan Kay attending some conference about OOP and saying that it was wrong, that he invented OOP and it was not like that.
IIRC, Kay's vision is that OOP is about messages.
I have my own pet theory, of course it must be wrong too, but if I may, only as food for thought: The core usefulness of OOP is usability. A language is a matter of connecting thoughts through a mental model. Subject, verb, predicate. Object, method, parameters. That's mostly it. The rest are implementation details and lots of bikeshedding.
This is the reason I find it useful. To me, OOP is as much about your organization as it is about the best way to load, transform, present, edit, and store data. I think the culture of some companies lends itself to various kinds of programming, but it's the cultureless companies where OOP is most useful. The places where nobody is trying to change the world, where people work to pay their mortgages, where an executive may only work for two years and a programmer may only work for six months.
It's in an environment like that where a self-documenting, self-configuring code base with custom classes and exceptions that guide the next developer is essential.
Every developer should have two users in mind. The person using the software, and the next developer who maintains the software after you're gone. OOP is a great way to empower the second user when the only thing that will reliably outlive the developer is the code base.
I think that OOP is the best way to accomplish the goals you list only if you stick to languages with mainstream appeal - but think it's sad that's the state of the world. Objects (as they are used in e.g. Java) default to stateful and complect data with the methods on that data. I find that most of the time what I want is closer to OCaml's Modules[0] which give me many of the tools of code organization without the complexity with state. (note that OCaml allows objects, so you get a real sense for how often you want an object over a module, 95% of the time I wanted a module).
This is one thing I like about Scala. While its classes can be used in the exact same manner as Java, that's not how its creators pitch them. I've seen them advocate using classes/objects akin to ML's modules, but there's enough flexibility to pivot if for some reason that does not make sense.
I want to second the idea that the primary benefit of OOP is logical organization.
For smaller projects I don't care one way or another about OOP practices, but once you start getting into hundreds of thousands of lines of code IMO it becomes an absolute necessity.
But we don't need classes, vector tables, or other runtime features to achieve organisation. We just need our compiler to recognise namespaces. "module Foo where"
Objects open up some advantages in how you snap together code that namespaces alone do not.
Code is much easier to deal with when you define abstractions around small sets of functionality and then allow the caller to pass in various objects that provide those functions to the code that needs it.
You can have an application that accepts a 'data_backend', and then provide a data_backend that just stores information into a dict for testing and getting the app initially written, one that tracks all of the changes made or exposes them for tests to check, or another that stores it to sqlite for running a local instance, and another that stores it to some real database for a larger one.
The calling code doesn't need to know what the data_backend does or how it works, it just tells it "store this", "read that" and the data_backend does whatever it does and data goes in and out of it.
You build up all your code that way and you'll be able to easily stub chunks and replace them with functional implementations, and then swap those out when needs change or by options given at runtime.
It's a lot easier to read and write than code that's littered with a million if statements trying to keep track of too much complexity in too many ways all at once.
OOP is just syntax sugar and compiler constraint enforcement for the same kinds of things you see the linux VFS do. There are many filesystems for linux, but each just provides a handful of functions in a structure that should be called against the structures representing the various types of filesystems. In Linux's C you have to slap it all through a (void *), but in languages with objects, you can use those as the medium of abstraction instead of doing it manually.
Some make you do a bunch of inheritance garbage with stapling objects together, others will let you build to interface definitions, or just check the structure of the object to see if it matches the needs of the caller, or be a dynamic language that just checks for the members at runtime.
If I create a REST API no one complains they don't have access to the inner-workings, local variables, etc. But if I give a similar experience and call it a "class" suddenly it's ugly and mean.
I find that's often because classes come with a lot of stuff that is less desirable - mainly inheritance and its assorted complexities.
The other side is that classes aren't the only way to get this sort of encapsulation. The classic example is closures - data inside the closure acts as the encapsulated data, and the returned type of the closure is its public API. ML languages typically use modules in place of classes - the module signature defines the public API, and rather than calling methods, you instead call functions with arguments (not `list.length()` but `length(list)`). But again, that's just syntax - we're keeping the same encapsulation because the module-defined functions are the only ones capable of fiddling with the value's internals. You also see this in Rust, which does use method syntax, but has traits and types that act more like modules than typical classes.
All in all, I don't think anyone's complaining about encapsulation, but rather it's a question of whether typical OOP (with all that that typically includes) is the best form of it.
Everything is wrong or illfitting. I mean we are making tiny blocks of silicon do extreme amounts of human work, while being entertained with music and videos. OOP is like five abstractions deeper than what it intend to model. It's a tool, I wish people stopped trying to make the extreme case of engineering that is software development some sort of axioms around physical law. Our expectations would be way better especially when our bosses require we implement a nosql db that stores rss feeds and use machine learning to sort them in order of "coolness".
There's very few actual rules despite opinionations derived from arbitrary paradigms and what should be done to work cohesively as a team. I wish there were a smidge less ivory towers and a smidge more common language.
> The core usefulness of OOP is usability. A language is a matter of connecting thoughts through a mental model.
Incidentally, this is exactly how I came to "reinvent" OOP as a newb programmer. I was working in a codebase where I didn't know what tools I had at my disposal, but we had a few modules where I could just type `module.` and see a list of all the methods, right there in front of me (in VSCode's intellisense). I asked, "Why don't we do this for our helper functions?" and we ended up with a handful of major objects to import with easily discoverable methods.
now of course I could have crawled the codebase to get the same information, but for someone new to programming and/or someone brand new to the codebase, that isn't necessarily a good use of a time. it can be a lot of slow unraveling of "what goes where", whereas organizing things in "OOP" (I still don't know if I'm actually using this term right because it was just part of how I learned, without being named) teaches that information more quickly through use and experimentation. basically what I was looking for was "namespacing" I guess, but I would also say it helped organize our code in a more useful way.
Runtime, multi-method dispatch is probably the singular thing that stands out as "missing" from other systems. I don't miss it a lot, but there have certainly been times when I have.
I also enjoyed the ability to not be locked into the rigor of a class structure when it comes to methods. Since CLOS is function based, it's trivial to add functions to a class that you don't even have the source code to.
There have been many times working with a 3rd party or system library where I've had that "if only I had this little method" moment that would make my life easier. I'd rather have that capability and fight, say, namespace issues for the "Well what if everyone added their own 'upshiftFirstLetter' method to the String class" problems on an ad hoc basis.
Part of this, of course, stems from the locked down nature of the scope of classes. Not having access to internal structures and state. I'd rather take those risks of leveraging internal state knowledge not supported by the original designer vs the alternatives of sometimes having to throw out the baby with the bathwater.
I haven't used it, so not sure if it fits the pattern, but the question for me is: is it useful, time-saving, more usable? does it make the task more clear for the programmer that uses it?
It depends. It is a fundamentally different branch of the OOP family tree than what most people are used to seeing. Enough so that I've seen people declare it to *not be OOP*. So if you stumble across the model having only seen the style of OOP popularized by C++ and later Java, no. You will probably *not* find it to be liberating.
The idea is that you have classes which model state. And then you have generics that model functionality. And you define methods which provide an implementation of the generic for a class. But it's more flexible than what you see in Java because such a method can be easily added after the fact as it's not intrinsically part of the class' definition.
If you're familiar at all with Typeclasses in Haskell & Scala, personally I find those to be similar enough to get the gist. Likewise Dylan and R's S4 objects are modeled after CLOS' structure.
combine a type system with dispatch logic, using abstractions .. it is very clear for some engineering applications and/or tinkertoys. Many people can get the basic ideas with thirty minutes of introduction.
But Smalltalk also has inheritance and metaclasses, so it wasn't just objects passing messages. It was also designed as a visual live programming environment which was basically the entire computer system. Kay had his vision, but Smalltalk was implemented as more than just message passing.
That and Simula proceeded Smalltalk, which C++ was inspired by, even if Kay coined OOP.
IIRC, Kay's vision is that OOP is about messages.
I have my own pet theory, of course it must be wrong too, but if I may, only as food for thought: The core usefulness of OOP is usability. A language is a matter of connecting thoughts through a mental model. Subject, verb, predicate. Object, method, parameters. That's mostly it. The rest are implementation details and lots of bikeshedding.