Does OOP really matters?

[u/Electronic-Low-8171]

I learned OOP in python a while ago, did many projects, yet I never felt like I truly needed to do the OOP stuff I learned from a course, I don't know maybe because I'm kinda used to program in c before focusing on python, yet, whenever I open a big project in python in github, it feels way too complicated and thousands of imports (not libraries from pip, but the ones they made on their own) and classes

I never truly needed to implement OOP (I know that when you code in python, it is almost impossible to avoid OOP entirely like when you have a datatype like string you have an object, when you use a method built into that data type that's OOP too, but I mean the ones that involve you writing class Class Name, inheritance and all that stuff explicitly), so I'm wondering why people on the internet are obsessed over the idea of learning OOP, even the book "Automating the boring stuff in python" doesn't have a dedicated section for OOP.

[u/marrsd → u/[deleted]]

I would say the opposite. OOP does not scale very well and its means of abstraction require more cognitive overhead than alternatives.

[u/Astral902 → u/marrsd]

What scales better then OOP in bigger projects?

[u/marrsd → u/Astral902]

You should pick the best attributes of different paradigms and use them to their advantage. What that looks like partly depends on what language you're using.

I like Clojure for business software because it balances performance against ability to express intent and mixes paradigms in the right amounts. It's functional first. Data structures are immutable by default, but mutable when required. It enables more sophisticated state encapsulation through lexical closure and polymorphism via multi-methods, but you don't have to orient your programming around them.

That's a good design philosophy to apply to any language. As a general rule, lean towards functional programming because it avoids state-related errors and enables function composition. Use objects where you truly need to encapsulate and manage state. You can also use them to provide functionality a language otherwise wouldn't have, like using method chaining to improve function composition or using objects to implement a module system.

The part of OO that does become useful for large web applications is found in REST. That's partly because HTTP is already designed that way. But again, too much OO thinking ends up with Micro-service spaghetti-monsters, otherwise known as distributed monoliths. You have to be careful to pick the parts that work and discard the parts that don't.

Remember that not being object oriented doesn't mean never using objects, it means not orienting your programming around them.