I’m a self-taught programmer, so have probably missed lots that might help, but every time I come across anything OO, it always seems unnecessarily complicated and awkwardly structured. It always seems (to me) that everything could be done more simply procedurally. I don’t get why.
Further, while I can follow OO code that others have written, as a beginner, how to structure something simple I’m writing de novo in an OOP style has a very steep learning curve.
But in modern OOP, understanding and simplicity are not what it's all about.
It's all about pushing the complexity into the language runtime stuff where it is no longer your problem.
OOP is popular because we can do stuff like port=DBConnection(); port.connect("foo.baz") and document= port.request("x").
Then, later on, when port and document are inaccessible, garbage collection will get them.
An OOP programmer doesn't think "Oh, the port.connect must make a socket and do a handshake and then..." they just think "It does all the port connect stuff".
As a student when the goal is to understand, OOP makes no sense, because encapsulation literally is all about making it so you don't need to think about things.
It lets you treat objects the same way we treat physical devices. Black boxes someone else built.
There's no beautiful reasoning or amazing objective logic saying OOP is better than I know of, or anything that even makes any sense at all if you think about it.
It just happens to work pretty well when people with a wide range of skill levels do large projects and nobody understands anything beyond their tiny part, and nobody really cares if things are simple under the hood.
If you want beauty and logic, learn a pure functional language or go study math.
And if you want to structure stuff in an modern OOP style, you just stop thinking in terms of simplicity and unified wholes and start thinking in terms of black boxes to be used by people who would be annoyed if they actually had to read the code.
Any entity you would talk about when describing the code is something that could be represented as an object.
Any collection of a variable number of a ton of entities like customers is something you could do as some kind of database connection object.
Any periodic task might be a "Machine" that is a class that manages a thread.
It's(In theory) a 1 to 1 mapping of ideas to classes, although some things just aren't worth a whole inventing object for and should probably be a data dict+procedural.
But, some would say this whole thing is nonsense for idiots who can't think, so maybe if you find yourself actually able to do procedural well you should try something more logical like haskell.
doX(data, args)
Here is OO:
data.doX(args)
The only difference is that you can stop doX(data, args) from modifying parts of data. However you can do the exact same thing in non-OO languages like C or Haskell by using void* (in C) or (in Haskell) modules with hidden constructors.
The only true OO language out there is Erlang. C++/Java/C# etc. are not OO languages.
The idea that OO is modelling the world is BS. You don't ask your shoe to tie itself or ask a tree to chop itself.
And you don't ask an integer to display itself in a dialog in an "OO" language unless you are a bad software designer.
Some people are really good it but it's a skill for sure and learning it is rough. It is some really abstract thinking shit, and difficult even to evaluate how well it has been done until much time has passed with it.
I think when people joke about naming in programming this is what they mean. Needing to clearly define relations that are not necessarily clear yet. OOP does demand a lot of that so is hard and exhausting in a particular way.
That said nothing against OOP I use it every day and Sandi Metz is the code book writer I learned the most useful stuff from. Just it's hard in a different way from most of the rest of coding.
Android development is the classic example - it's ALL OO - and most of the time, that's pushing the proverbial uphill. Instead of just initialise something, everything is pushed into constructors. The model works sometimes, but for many things it just adds work. AND ADDS ENORMOUS AMOUNTS OF BOILERPLATE. Aarrgghhh.