There are so many definitions of OOP out there, varying between different books, documentation and articles.
What really defines OOP?
You’re getting a lot of conceptual definitions, but mechanically, it’s just:
keeping state (data) and behavior (functions) that operate on that state, together
At minimum, that’s it. All the other things (encapsulation, message passing, inheritance, etc) are for solidifying that concept further or for extending the paradigm with features.
For example, you can express OOP semantics without OOP syntax:
foo_dict.add(key, val) # OOP syntax dict_add(foo_dict, key, val) # OOP semanticsDude, you’re going to shit bricks when you realize most computer science jargon is just marketing buzzwords on top of marketing buzzwords and the terms never meant anything more or less it needed to sell a product.
For example, what the hell is big data? What is a scripting language? Is your DB web scale?
For example, what the hell is big data?
Big data is when we align our agile synergies at scale.
Vertical integration!
That one phrase does mean something though, and it should be fucking illegal.
OOP on its most fundamental level is the principle that stuff is represented by objects and those objects communicate with each other. That’s it, that’s the whole OOP.
What you are probably referring to is how OOP solves different problems and the different patterns it uses. Those are not OOP itself, those are basically instructions on how to do OOP correctly without shooting yourself in the foot.
So SOLID, IoC, dependency injection, factory, composition over inheritance and all the other famous principles are not OOP itself, but any medium-size app that’s not following them is set for really fun times ~5 years down the road.
Not sure if I’ve answered your question, it’s really vague, feel free to ask further.
Does it really matter? This knowledge won’t help you in writing code.
OOP is one of, if not the most popular programming paradigm. Surely understanding it at a theoretical level isn’t useless. It would be the first step to understanding its benefits and trade offs.
Use it for a while, to complement your theoretical study. Things will only become clearer when you have your own understanding and opinion about it.
How would one use it if they’re struggling to understand it to start with? 🤨
You are right. But I still find the ‘heavier’ theory, that is what I assumed OP refered to, to be more difficult to grasp then following a basic tutorial and just trying to solve problems. In time with practice you get a better understanding for WHY the theory is how it is, and you can apply it better and of course improve your code. And that understanding will unlock more tools both in OOP and in your mind.
So if you are struggling, I recommend not starting with theory.
It’s similar to any tech buzzword. Take “agile” for example. Agile was successfully sold as being a great idea without really being well-defined. Suddenly anyone selling a development methodology had a strong incentive to pitch it as being the real way to do agile development.
In the 90s and 2000s every 10x california tech guru agreed that OO was the future, but apparently none of them actually liked smalltalk. Instead, every new language with a hint of dynamic dispatch suddenly claimed to represent the truest virtues of OO.
There are also people who argue that smalltalk is not true OO. They say that by Alan Kay’s own definition the most OO language is Erlang.
I think it’s most useful to learn about that history, instead of worrying about people’s post-hoc academic definitions.
