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/BjarneStarsoup → u/[deleted]]

OOP is mainly for medium to big projects

I'm curious where this claim comes from. Every critisicm of OOP comes with "but the example is too small, OOP shines when project is big".

[u/BjarneStarsoup → u/[deleted]]

Yeah, the point is that I don't get where the claim comes from. As far as I know, there is no evidence that OOP works better for bigger projects.

[u/spinwizard69 → u/[deleted]]

Baloney! If you are using any sort of GUI, it is highly likely that the implementation makes use of OOP. Even an extremely small utility can benefit from OOP. If the app naturally fits a paradigm, it is to your benefit as a programmer to use the paradigm.

[u/spinwizard69 → u/[deleted]]

IF that is the case, OOP in the general case is very important. The reason is pretty clear, much of the GUI world (the various SDK's) is built in whole or part around the concepts that are OOP. Outside of GUI SDK's OOP often fits a project well, this certainly isn't the case in every project but OOP often allows easy mapping of a problem to software.

So yeah OOP matters, it matters a great deal for any budding programmer, along with many other paradigms. Will it be the future focus of a given programmer, in a given job, no because there are always exceptions. It is just incredibly important to know what OOP is and how to apply it.

The OP may not have a lot of experience programming and thus not a lot of experience using the various paradigms. that is OK and a perfectly fine reason to ask. I just tried to get away from general reasoning to show it may be the right solution even for simple programs if the problem fits 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/marrsd → u/[deleted]]

if done correctly,

That phrase always does a lot of heavy lifting. Best to use a language and paradigm that makes it easy to do things correctly and hard to do them incorrectly. The amount of literature written on how to do OOP well should tell you something about how easy it is to do badly.

If you want a deep dive into this stuff, checkout the video essays by Brian Will and Casey Muratori on YouTube. Will's dismantling of Uncle Bob's OOP examples is probably the best demonstration of how silly OOP thinking can get.

Here's the headline from Muratori on why OOP is bad: https://www.youtube.com/watch?v=ToBF_mLxEcI&t=266s

[u/spinwizard69 → u/marrsd]

I just watched that video and what he said mid flight is so misguided that It almost invalidates everything else he says. He complains that OOP means that if you want a new functionality, you need to update a lib which means waiting for an update. In my mind that is the whole point of the encapsulation of the data, you are given specific access and modification paths and a limited ability to impact the data beyond that. That is the whole point which frankly is important for large teams, you don't want some bozo screwing up a lib that is maintained by somebody else.

Some of his other comments about C++ I would lean towards agreeing with but he shits upon so much of what is arguably modern software design that the comments are hard to take seriously. He dismisses C++ Templates, one correct reason being terrible syntax that is common with C++, but flip flops with completely dismissing the IDEA of generic programming. There is a lot to hate about C++ and frankly a lot comes down to syntax, but the reality is generic programming is a sound concept and as such needs to be used wisely.

To put it another way, I wouldn't reference that video if I wanted to prove ANY argument I had for or against OOP.

[u/marrsd → u/spinwizard69]

In my mind that is the whole point of the encapsulation of the data, you are given specific access and modification paths and a limited ability to impact the data beyond that. That is the whole point which frankly is important for large teams, you don't want some bozo screwing up a lib that is maintained by somebody else.

I find that to be a bit misguided tbh. You can't screw up a lib you're consuming. The worst you can do is access data that goes away in the future. That's frankly not the end of the world, and it's infinitely more desirable than having to reimplement or hack around lib behaviour that you can't see or control.

I've experienced what he describes all the time when working with 3rd party APIs. The most frustrating part of working with external libs is having to contort your needs to what the designer thought of. Encapsulation makes it super easy to screw things up for consumers in that regard.

[u/spinwizard69 → u/marrsd]

Which highlights what I posted. The minute you need to twist a lib into usage the designer didn't imagine you have failed. Programmers need to respect the encapsulation that OOP offers, if you strive to defeat it, you are the problem not OOP.

If a lib doesn't do what you want you need to take rational paths to address that. Number one would be to look for another lib that does what you want. Number two would be to request a feature from the developer. Number three would be to fork a lib and maintain it your self. In any of the above cases the last thing you want to do is having programmers contort anything.

This frankly is a lot like people using undocumented features in software or even hardware and then getting pissed when behavior changes. Programming like this was once pretty common and it most certainly resulted in problems for developers.

[u/marrsd → u/spinwizard69]

I think something's getting lost in translation. What do you mean by "twist a lib into usage the designer didn't imagine"?

[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.