Where do I start. OOP is not a discipline, it's a paradigm, a mode of thinking about how programming ought to be.
OOP is not primarily about data structures. Not at all. An object is mostly an abstract interface. It might have some data, or it might not. Many OOP practices encourage creating objects that only hold references to other objects and no concrete data at all.
The problem with programming is that computers can only ever move data around and perform some arithmetic operations on them. That's really all they do. Everything else is built on top of that.
Display, audio, and networking at just I/O operations, and I/O to the CPU just looks like reading/writing to and from memory.
There are levels of abstractions, and often times it's beneficial to isolate lower level concerns from higher level concerns.
You can do that just fine with good old procedures.
Sometimes, it's beneficial to have "abstract" objects that could potentially have many different implementations. A file system is the thing that comes to mind most of the time. I can read/write to files without worrying about the underlying file system. That's a good thing.
Not everything is a file system though! Not everything needs to be abstracted and hidden.
The criticism against OOP is usually around the level of granularity.
Within your own code base, you want to know how everything works. You don't want to _hide_ things from yourself.
It might be useful to limit the scope of visibility for some fields, but it's always on an "it depends" basis.
OOP wants you to make strong boundary modules on very small scales, and it comes with absolute rules to help enforce that, like always making everything private by default, and always dealing with abstract objects instead of concrete data and procedures.
When the QT below says that OO is a discipline, they mean that following the OO heuristics is always the right thing to do and it's better to just always do it and get used to doing it, and you don't get to argue about it, just like you always fasten your seat belt, always take a daily shower, always brush your teeth before bed, always go to the gym on schedule, always follow the correct diet. Don't second guess yourself every other step. Just do the right things and you will get the good results.
The problem of course is that you do not get the good results from following the OO rules because they are wrong when applied as such.
Some things can be useful all the time and you should do them even if they bother you a little bit, like fastening your seat belt.
Some things are useful some of the time but not other times, like taking the highway vs the regular road, riding the train vs calling a taxi.
The answer is always "it depends".
This is not to say that there are no heuristics.
There are, but not everyone agrees on them.
Different groups of programmers have different heuristics. Some of them overlap, some of them don't.
Some of my heuristics that I found to be immensely helpful in making programs easier to understand and reason about:
- Prefer regular data and procedures
- Prefer languages where structs have value semantics (as opposed to reference semantics)
- Zero value initialization by default
Everything else is "it depends".
How big should the file be? It depends.
How long should a function be? It depends.
How big should a module be? It depends.
OO is a discipline in which data structures are hidden behind dedicated functions that are called through a jump table.
If you take out the jump table then you get “object based” programming. If you then remove the words “hidden” and “dedicated” you get regular old programming.
So when people say that OOP is bad, which of those three constraints are they referring to?
It can’t be the jump table because the utility is obvious and the cost is virtually zero.
It can’t be “dedicated” or “hidden” because those constraints are optional in virtually all OOPLs.
The only conclusion I can come to is that they have no rationale but have their own favorite style. They don’t understand that style well enough to tout its virtues and so fall back on disparaging others.