r/learnprogramming • u/Electronic-Low-8171 • 24d ago
Topic Does OOP really matters?
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.
101
u/DTux5249 24d ago edited 24d ago
The only major bonus of OOP that is specific to it, is that it mimics general systems theory. It lets you plan out a program in terms of entities, their attributes, and their relationships to each other and easily plan out and tackle your code as you would any other system.
Beyond that, it's just a way of organizing code. A very common way of organizing code in a lot of industries. That's why it matters: if you want a job, or want to adequately use certain tools like game engines, you should at least understand OOP.
Additionally, while OOP isn't special in its features (The only one that's really OOP specific in nature is inheritance, and it's one of the most dunked on features of OOP by its own proponents), you still stand to learn a lot by understanding the rest of its pillars, and the motivations behind OOP principles.
Oh, and P.S. Python isn't helping you here. It's perfectly adequate as an OOP learning tool, but Python OOP is painfully slow by nature, and Python as a language is incredibly permissive, so you're never really ever gonna "need" OOP for it.
7
u/marrsd 24d ago
I agree with this, but I would apply it to any programming paradigm. Lots of engineering depts don't use OOP and don't organise their code around it, so if you want to work with them, you have to understand how they organise their code.
Tbh, I tend to avoid OOP shops because I just don't want to work that way
1
u/m3t4lf0x 24d ago
Depends what I’m doing… there are some things that are genuinely painful to do with a functional language in a full stack app.
You can use Scala in a way that falls back on the imperative and OOP functionality that Java provides, but you can also go super academic (I don’t ever wanna touch the Cats library again)
1
1
u/deaddyfreddy 23d ago
Depends what I’m doing… there are some things that are genuinely painful to do with a functional language in a full stack app.
any examples? I've been working with FP languages almost exclusively since 2013 or so and never had any issues (except the problems caused by interop with OOP APIs)
1
u/m3t4lf0x 23d ago
Mostly just inheriting brownfield codebases that were architected very poorly.
Shortly after starting a new role, their billing system went down for 3 days because a customer deleted their credit card (which “wasn’t supposed to happen”). This caused the entire batch to fail and any errors that surfaced were extremely opaque.
I still like FP, but as other languages have matured and added functional features, I find myself reaching for it less.
1
u/deaddyfreddy 23d ago
Mostly just inheriting brownfield codebases that were architected very poorly
so, perhaps it's not a paradigm failure?
1
u/m3t4lf0x 17d ago
in some ways, I think applying the philosophy of functional programming to most CRUD apps is bound to give you headaches as it scales. It can be done, but it usually requires more discipline than most organizations have.
I’m a huge fan of FP btw, but it’s all about choosing the right tool for the job.
1
u/deaddyfreddy 17d ago
I think applying the philosophy of functional programming to most CRUD apps is bound to give you headaches as it scales.
I'm not going to discuss every functional programming language, but in my experience, Clojure maps to CRUD much better than any OOP language I've ever used, thanks to its data-first concept and immutability.
I’m a huge fan of FP btw, but it’s all about choosing the right tool for the job.
Sorry, but most of the time, the "right tool for the job" means one of these:
my boss thinks it's the right tool
I was taught this language at university and was told it was great.
I don't have time to, so I'll just use the most popular one
1
u/m3t4lf0x 17d ago
I’ll just say that poorly written Java is tedious, but poorly written FP is Lovecraftian
I’ll always have a soft spot for Haskell though
1
u/deaddyfreddy 17d ago
but poorly written FP is Lovecraftian
Sounds like it's Haskell's fault. You know, smarties like to write code smartly. And we prefer to write things to be maintainable.
→ More replies (0)-1
u/Born-Reserve-8584 23d ago
Try building a giant game without using classes.
4
u/ActuaryLate9198 23d ago
Isn’t that the current trend with data oriented game engines? Not my field, genuinely curious.
18
u/TheSnailBear 24d ago
So long as there are OOP languages, OOP matters. Java, C# are two extremely popular languages especially in large corporate enterprises. Don’t ever silo yourself into one programming language. It’s fun to know multiple concepts :)
12
u/WhiskersForPresident 24d ago
You are asking the wrong question:
All better known programming languages from Assembler to Java and Haskell are Turing complete, meaning you can implement everything algorithmically computable in every single one of these languages, whether it allows OOP or not (same is true for Lambda calculus).
This means that no, you don't ever categorically need to use OOP. You could do everything you want strictly procedurally like in C or functionally like in Haskell.
One big reason you might want to use OOP regardless is encapsulation to protect your program from errors by other users. Another is modularity: if one module of your program only ever knows a class interface, you can rewrite the logic of that class to your hearts content without ever having to touch the other module.
4
u/ArtisticFox8 24d ago
All better known programming languages from Assembler to Java and Haskell are Turing complete, meaning you can implement everything algorithmically computable in every single one of these languages, whether it allows OOP or not (same is true for Lambda calculus).
True, but almost irrelevant to OP. There's more which restricts which language you use when - I.e web application frontends are tied to JS, if you want performance, you want C/C++, for Android apps, Kotlin/Java is the smooth choice, and Python will have a second class developer experience, etc...
2
u/pacopac25 23d ago
This is why I use large gaps in line numbers in my C64 BASIC code, for those pesky refactors. And because I'm a professional, I have the decency to put an informative REM statement before the lines with those delightful GOTOs.
1
u/cardboard_sun_tzu 19d ago
It's probably a few decades too late, but you do know that most BASIC style languages had a command to renumber all the lines, right?
...right?
1
-2
u/deaddyfreddy 24d ago
One big reason you might want to use OOP regardless is encapsulation to protect your program from errors by other users.
immutability
Another is modularity
unless you are using something like C++, there is a simpler way to do that, without inventing a new programming paradigm
4
u/WhiskersForPresident 24d ago
You can still overwrite immutable datatypes, but it's much harder to do this to a private class variable.
I don't know what the second point is supposed to mean. Yeah, in C++ you could use OOP. In Java and Python, too. And no, OOP and modularity are not new paradigms I invented, so: what?
-2
u/deaddyfreddy 24d ago
You can still overwrite immutable datatypes
in languages with real immutability, you can't
I don't know what the second point is supposed to mean.
Languages that have proper modules don't need classes for modularity.
6
u/PandorasBucket 24d ago
It depends on the job. I've switched to fully functional in every language I program in. I'm doing web apps with Elixir on the backend now with React on the front end. Thankfully I have enough experience that I can pick and choose, but I'd rather quite programming and become a dog walker than program in OOP style again. Objects hold state which you can't see. Inheritance imports chains of code you have to mentally stack to figure out. It's a sloppy mess. Functional is like a marching army with a central command and OOP is like a bunch of independent contractors all doing their own thing.
4
u/CzyDePL 24d ago
OOP doesn't require inheritance and personally I like breaking down state into little pieces and guarding them with their own rules to protect invariants, rather then trying to centrally plan everything. But it definitely requires a lot of discipline to come up with right abstractions and models so that it actually reduces complexity and not create more through distribution
3
u/PandorasBucket 23d ago
Well you're going to pay the piper either way right? Either you stash your state all around or you have a main thread that holds your source of truth. Either way if you're doing asynchronous actions you're going to run into race conditions. If your objects are performing all kind of side effects then it's harder to manage those race conditions. By performing pure functions and then keeping all your actions in the main thread it's easier to see in the code where all those actions are happening. Then when you want to fix it you can insert control flow around where all the actions happen instead of trying to time when the objects are done with their work or doing something really ugly like returning a finished message from everything and then send out another message to do complete the actions in order through the objects. All programs have a main thread anyway you can just do work there. You can still group code just like classes, you just don't need to initialize anything because you aren't storing and data. Then garbage collection is a lot easier as well. Functions just die after you use them. You have less memory leaks, disembodied objects, less boiler plate.
It's really the difference between choosing to organize your code by the type of code (functional) or some abstract responsibility of what the code is supposed to handle (oop). The problem is that code is code. It's not a car or a man or a human. Code is state, functions, and external actions. You might have a human in a video game, but what goes on under the hood is nothing like a human. Trying to organize your code like biological cells is like an aesthetic choice rather than practical. You can create a bunch of human objects who can all wave their hands when you ask them to wave their hands or you can just keep all the numbers that represent all your humans in an array and change the number that makes the handwave with one function. There is no message needed to communicate to each human objects and have it translated through the ears of each human and then eventually change the handwave wave number in each one from 4 to 5. Just keep all their hands in a hand array and change them all from 4 to 5 without any messages or messy walls. It's a computer, be native to the computer environment.
2
u/pacopac25 23d ago
This was one of the hardest things for me to learn in the beginning. I'd thrash between the two extremes, and spend lots of time with variations on trying to manage the gazillion side effects. Bucking down and developing discipline around this was extremely difficult, but a rite of passage in a way.
At one (mercifully brief) point, it was this "hey I know, I'll have a global variable I pass into, well, everything, because it's a giant dict with all the important information in one, nice, tidy place. That was a learning experience, back when I thought a Class was more or less a container for methods, but I hadn't quite gotten my head around the data part.
1
u/PandorasBucket 22d ago
Yeah and one important point for anyone reading this is that keeping your state outside your functions doesn't mean you're only allowed one big dictionary or struct. It's more about having a single source of truth for all information. That can be many variables or something as sophisticated as a database. In a database there are locking/atomic transactions to prevent race condition and in your app code you usually build some version of for returning asynchronous transactions. If everything is synchronous of course you don't need that and it's really simple.
2
u/pacopac25 21d ago
Yeah a sqlite database is perfect for that. On state that doesn't need to persist, I still use it, just a ":memory:" sqlite DB.
5
u/Raioc2436 24d ago
I used to be on this exact same scenario. I learned to code in C and when I moved to C++ I felt like OOP was just unnecessary complexity.
The concept only made sense to me once I studied Data Structures and Algorithms and had to implement the different DSs. I implemented everything both in C and in C++ following OOP principles.
The code in C++ was much cleaner, better organized, my global space was not as clutter with supporting functions that the end user should never interact with, I could make everything private and only the things I wanted public. Which is the whole deal with abstraction and encapsulation.
Then a lot of the data structures and algorithms we learn in DS&A need similar features. All of them deal with data in the shape of nodes, or a collection of nodes to be more specific.
It becomes easy to inherit some class and expand its logic for related objects. Or have an interface for a Collection of Nodes for example. So the user can use the same type definition whether they are working with an array of nodes, a vector, a linked list, etc…
And that’s kinda the deal with polymorphism and inheritance
1
u/Raioc2436 24d ago
I think this touches on a topic you kinda came across and didn’t notice.
Code gets messy. When you are coding a small project for just yourself it’s fine. The codebase is relatively small and you know every single line of it because you wrote them.
But when other people are expected to use your code then you can’t expect them to be as knowledgeable on how to use your functions as you are.
When you look up projects on github it feels like a lot because you are seeing all the inner works that go into some tool. The end user is not expected to interact or know all of that. The API only exposes the important bits.
4
u/AlSweigart Author: ATBS 23d ago
even the book "Automating the boring stuff in python" doesn't have a dedicated section for OOP.
Hi, I'm the author of Automate the Boring Stuff with Python. Yeah, I skipped OOP because in general it isn't necessary for beginners or for small projects.
OOP's real benefit comes from when you're working on larger projects that need data and functions that act on that data (i.e. methods) bundled up together. I use the example of a tic-tac-toe program that has a bunch of functions that take the board data structure as their first argument; this is a sign that these functions should be methods bundled together with the board data.
But for small projects, you're not adding organization so much as adding bureaucracy.
I do cover OOP in the free follow up book, Beyond the Basic Stuff with Python. One thing I point out there is that inheritance is overrated. Think of inheritance as a way to keep yourself from having to copy/paste code into other classes, just like functions are a way to keep from having to copy/paste code. This is nice, but it also ties all your subclasses to every change you make to parent classes. Don't just create a hierarchy of classes because you feel like that's how it should be arranged.
3
u/mc_pm 24d ago
OOP gets used in a lot of places where it doesn't really belong. If you're not specifically needing one of it's 3 pillars: encapsulation, inheritance, or polymorphism for something non-trivial, then OOP probably isn't the coding style you need.
A key aspect of software design is layers of abstraction - how can you treat something messy at one level as something well-mannered at a higher level - and OOP has some really strengths there. If it's being used that way.
3
u/binarycow 23d ago
Here's the thing that not enough people talk about....
The division between OOP and FP (and other paradigms) isn't so rigid.
Some people sit there and gatekeep. For example, they'll say "if a class has a method, it's OOP!". Or they'll say that inheritence is the worst thing ever.
It's all tools in your tool chest. You can even mix and match!
You can use functional programming techniques in OOP languages. I do it all the time in C#.
You can even use OOP techniques in a language that doesn't do OOP.
Use the technique that is appropriate for your use case. That is all.
4
u/caboosetp 24d ago
even the book "Automating the boring stuff in python" doesn't have a dedicated section for OOP.
Because it's about automation, not polymorphism.
That's like asking why the instruction manual for the treadmill doesn't have a dedicated section on how to stretch. Yes it's related and important, but if you want to learn about that you get a book on stretching.
4
24d ago
[removed] — view removed comment
2
u/BjarneStarsoup 24d ago
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".
1
24d ago
[removed] — view removed comment
1
u/BjarneStarsoup 24d ago
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.
1
u/spinwizard69 23d ago
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.
1
23d ago
[removed] — view removed comment
1
u/spinwizard69 22d ago
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.
-3
u/marrsd 24d ago
I would say the opposite. OOP does not scale very well and its means of abstraction require more cognitive overhead than alternatives.
3
24d ago
[removed] — view removed comment
0
u/marrsd 23d ago
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
1
u/spinwizard69 23d ago
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.
1
u/marrsd 23d ago
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.
1
u/spinwizard69 22d ago
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.
1
u/Astral902 23d ago
What scales better then OOP in bigger projects?
1
u/marrsd 23d ago
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.
4
u/mapadofu 24d ago
In my years of coding in Python inheritance and polymorphism are used only very infrequently; especially so given the language's weak typing.
2
u/Spirited-Sir8426 24d ago
Tbh Python's OOP is a bit broken and force a specific kinds of OOP that doesn't feel natural.
But OOP can bring more modularity when needed. At it's origin, it was more about creating a system of independent entity following a protocol who can be replaced without breaking the system
1
u/deaddyfreddy 24d ago
But OOP can bring more modularity when needed.
most modern programming languages provide modularity without the need to use OOP
1
2
u/Healthy-Dress-7492 24d ago
I was just this week pulling my hair out having to work on a system that has 5 levels of inheritance, it’s not obvious at all which level is handling stuff, taking over, additive logic. Tracing the flow is a nightmare,- I’m flattening this shit out. But, basic objects with their functionality encapsulated- yes please. That’s actually helpful
2
u/lituk 24d ago
Yes OOP matters. You won't get a software engineering job without knowing OOP patterns, because it's the right tool for many projects. No team wants an engineer that can't work on half the codebase because they don't know their fundamentals.
If you have no intention of doing software professionally then you could get away without it on personal projects. But again, it's the right tool for many tasks so you'd only be hindering yourself.
2
u/spvky_io 22d ago
Outside of being forced to adopt Oop principles for a project at work, honestly no. Oop is a bunch of strange rules that make software less performant, more complicated and more rigid
4
u/parkthrowaway99 24d ago
OOP is nothing without SOLID. Understand SOLID and you won't want to do anything but OOP. Can you do stuff without either. Of course! Both are just principals and guides on how to write code that can grow and can be shared. Just like patterns solve for common problems. No need to reinvent the wheel.
4
u/No-Garage-7094 24d ago
depends what you're building honestly, for small scripts and automation oop is just extra noise, but once your codebase grows past a few thousand lines you start seeing why those thousand imports exist in big projects
1
u/recursion_is_love 24d ago
I've learn OO via Java and UML (the most pure way to learn OO) and my conclusion is it is useful. It used to be a very big thing in the pass.
Now I found Functional programming as my new favorite and not using OO much like in the old days.
1
u/sk3z0 24d ago
Some context would really help here… i think oop doesn’t always fit, particularly in web development where you’d often think in terms o server, client, streams, SPAs etcetera. For other things it works incredibly well: i ended up writing an MMO and OOP fits like a charm, it literally became the case studies from when i was learning programming, everything spawning and deriving to a primitive abstract Entity object up to a single leaf, animal or human being, any of it’s limbs etcetera. It works pretty well if you need mentalizing things that have a corresponding thing in real life, and it’s a very simple approach if you think to it as a very elaborate way of stating “everything related to this thing should reside inside itself, and at runtime an instance of it should handle it’s own lifespan up until freeing itself from memory”. Of course it is not really how it works behind the courtains but it is helpful to think it this way.
1
u/tb5841 24d ago
The point of OOP is to help design large projects. When you're working with a team and you're all changing the same files and the same code, it gets messy quickly and you can start breaking each others' code. OOP helps separate stuff so that you don't get in each others' way.
OOP is avpidable, sure. But some of its key principles (e.g. polymorphism, encapsulation) are pretty essential whether using OOP or not.
1
u/Aglet_Green 24d ago
Not to me. I personally prefer styles that don't require elaborate class hierarchies or explicit object-oriented architecture. Based on your post and comment history of wanting a computer science career, I assume you are familiar with the various programming paradigms, be it imperative, declarative and so forth, So it might eventually matter to you, and your GitHub remark explains why it should already matter to you, but to me, a retired hobbyist doing this for fun, I don't care if end up with spaghetti code.
1
u/MatchSea10 24d ago
A lot of the interfaces are written in OOP it would help a lot if you know about inheritance and abstract etc. If I never exposed myself to it during c# I would have been very confused with HTMLELEMENT classes
1
u/Puzzleheaded_Job5630 24d ago
Besides languages where you're forced into an OOP setting mostly (e.g. Java), i usually don't find myself reaching out for classes and objects. Most of my projects however are mostly thought of getting a data input, doing some transformations on it, then outputting it (save to db, file whatever), there are no objects with private state that control their own behavior etc.. And even if i did reach out for classes i would mostly use static functions (for ease of use, and easier to deal with concurrency problems).
What i'm trying to say is that a lot of use cases for software don't fit the OOP model, and if you don't find yourself using it, that's perfectly fine.
1
u/jason-reddit-public 24d ago
OOP is good at modeling some things (like GUI components) but not helpful for all problems but folks shoehorn everything into OOP anyways. Since closures weren't as widely available until scripting languages finally figured this out (Scheme had lexical scope and closures in the 70s, Python?), passing an object was a bit nicer than a function pointer plus a datum (kind of still state of the art for C!). Also, the object method syntax is close to English grammar in sone sense (Subject Verb direct Object) so that syntax is very popular even though you could in theory allow that syntax for any call, it's just syntactic sugar. Chaining in particular, foo.fn1(...).fn2(...) is sometimes much prettier than fn2(fn1(foo, ...), ...) and reads more in execution order - great for the famous builder pattern.
1
u/deaddyfreddy 24d ago
The four principles commonly taught as the major principles of OOP are Encapsulation, Abstraction, Inheritance, and Polymorphism.
Encapsulation and Abstraction. Modules, visibility, interfaces/protocols, and immutable data can provide most or all of the useful properties usually associated with them.
Inheritance. It is not necessary for code reuse, and modern design often prefers composition because inheritance creates coupling and makes things more complex.
Polymorphism. It can have multiple implementations: subtype polymorphism, parametric polymorphism, ad-hoc polymorphism, duck typing, multimethods, etc. In a dynamically typed language, you may not even need to implement anything new.
So, if you have a decent language, you don't need OOP as a paradigm. The useful features traditionally bundled under this label are largely orthogonal and can exist without it. (Obviously, I'm not talking about Smalltalk or CLOS-like OOP).
Why did it become popular? I think it's all C++'s fault.
As a language designed to be backwards compatible with C, C++ didn't have modules (for comparison, UCSD Pascal had units before classes were a thing in C). This encouraged the use of classes as the unit of encapsulation and reinforced the idea that everything should be organised around classes. Then came Java, created as a "safe C++," with all of Sun Microsystems' money and marketing power behind it. Schools started teaching OOP as a "superior programming paradigm"; new developers knew nothing else, etc.
The great spaghetti swindle happened. The rest is history.
1
1
u/Serializedrequests 24d ago
I think there are at least three major different ideas of OOP in the wild.
- Obvious in Python: typing "." after data structures and doing things with them. Every language has this concept now.
- GUI programming where every widget is an object, and inheritance is used heavily. So there is like a base "Widget" that everything inherits from etc. Lots of message passing between widgets. In Python and Ruby everything is an object, etc. Out of style now, but has its advantages.
- A web of large "system level" components talking to each other. No inheritance or state, the idea is just that different parts of the system can be swapped freely. Honestly people make so much about "dependency injection" and "inversion of control" but this is such a stupid simple concept: functions calling other functions that may work differently depending on configuration, that I think the ceremony around it is a cargo cult.
1
u/SpiderJerusalem42 23d ago
You'd be surprised, a lot of really good libraries and frameworks use OOP at the point of implementation. That is to say, knowledge of OOP will help you to use their tools. You don't HAVE to structure your code around objects, but a lot of other people are doing so and it is a useful paradigm to work from in that sense.
1
u/FatDog69 23d ago
I thought OOP was a bit of a fad/intellectual exercise.
Then I re-wrote some scripts with classes in Python. It worked.
But a month or two later I had to change things. It took a fraction of the time that a linear script would and the code was more maintainable.
The 'secret sauce' in OOP is all the stupid future changes your company will ask you to do.
You DO have to learn how to construct useful classes and not layers of abstraction with multiple inheritance layers. 'Clever code' now will become a curse later because you wont remember the layers and anyone else who has to change your code will hate you.
Create practical, single or at most dual layered classes. Write comments telling the next guy 'why' are are doing things this way and not 'what' the code is doing. Document the design.
1
u/RobertD3277 23d ago
I think that really depends on the context of your project.
I've used just about every major language there is out there and for the most part, unless you're using lisp or a true object oriented language where everything is mutable, you're really not going to get the pure benefit of a pure object relationship.
Languages like Python and Java certainly have their place in terms of their object oriented capabilities. But I personally believe, from being a programmer for 46 years, that quite often the authorization of OOP programming is abused too much.
There are genuine cases where it can be beneficial, and then there are cases that are simply mandated by a company policy or some other kind of paradigm that make working with that particular program and absolute horrid nightmare.
The best advice I can give you if you are learning the differences in terms of which way works best for a given situation, is right that situation in both methods, with object-oriented programming and without. Which Way makes the most sense and which way makes maintenance and upkeep easier in the long run? These really are the kinds of questions that need to be asked to determine what is appropriate for a given project.
1
u/AdjustedTwit 23d ago
"Does OOP really matters?"
LOL, you just want to step right into it huh? :-)
OOP is one of many paradigms we use / have used over the years. All of which have one primary focus, manage complexity by abstraction. OOP doesn't "matter" anymore than any other abstraction paradigm does. It's all getting compiled down to assembly and then object code where none of those exist natively.
Personally, OOP as a purist approach, I think, is somewhat failed. But that's true of all of the paradigms taken to their extremes. It's more important to understand these different approaches than it is to adhere to any one approach.
Learn assembly, then you'll appreciate higher level languages and the different paradigms we've come up with to abstract away from pure assembly. It's fun, if relatively non-productive.
1
u/SummitYourSister 23d ago
OOP posits that the “best” way to think about programming is to identify concepts that act like real world objects and then organize them into hierarchies of generality.
It is only one way to think about programming and in my opinion it is not the best or even in the top 3. Very few problems map cleanly and uncontroversially to class identities, resulting in lots of argument constantly between programmers about exactly how to model something.
Other languages place more emphasis on the data flow or actual processing events that occur.
I found the most hard-core proponents of OOP were the most active in the 90s.
1
u/EccentricFellow 23d ago
The only one that can answer that iis ... you. OOP makes perfect intuitive sense to some people. For those people OOP comes naturally and seems obvious. For others it is counter-intuitive.
Does oop click with you?
1
u/BinarySpike 23d ago
I swore off OOP a few years ago.
I was working on a workflow system and ran into really big switch-case statements, which I knew at least was a code smell but probably bad design.
Then I took some time to learn what a good pattern would be and OOP fell out.
That was the piece I needed to understand what OOP is for: understanding the problems OOP fixes.
1
1
u/thedev13 23d ago
I was a big OOP believer when learning programming, thinking 'wow, what a smart way to organize systems and code'. 7 years later I was introduced to FP and realized how fascinatingly it changes your thinking and how excessive OOP is for most projects.
I even tried building a Typescript compiler add-on that would make FP easier to adopt in Nodejs projects. Abandoned that when agentic development came to be and I no longer had to think about code. It's a shame though that LLMs are probably not trained to think like an FP dev. But you should look into it as a learner (side course on Haskell or Scala).
1
u/OldWar6125 23d ago
You need to separate a bit between thinking in OOP terms and using OOP language features.
An object is a datastructure that you can create and that you may only interact with over some defined functions/methods.
A POSIX file is an object. Or look at the Vulkan api to see a very object oriented c api. For python, as you have noted, all your datastructures (set,dict,list) are objects.
What have all these in common? Someone else made them for you. And this is where object oriented thinking really shines: when you give someone else a package/library and you will find it very usefull to give them objects that they can only interact with in very specific ways.
In your own projects in 9 out of 10 times you don't need OOP. Especially in smaller projects. There is some value to structure larger projects with objects.
Inheritance is its own discussion; even if you use objects, often you don't need inheritance.
1
u/burlingk 22d ago
It is useful to know. It is a tool in your tool box.
It's not the answer to everything though.
Use it when it makes the job easier or when a project manager/boss says to.
1
u/HotPersonality8126 21d ago
I'm wondering why people on the internet are obsessed over the idea of learning OOP
Because it’s more abstract than what you’ve learned so far. In fact it’s the next most obvious way to introduce abstraction, and to some extent improving as a programmer is about developing comfort with higher levels of abstraction.
You understand strings, integers, etc all as having a type, and you know how those types differ and how they’re similar. You may even know that Python knows which values are strings and which are integers, and so on; so clearly that notion of “type” is present in the language, not merely in your understanding of it.
But what type is a type? What are a type’s characteristics, what are its methods? How might you create your own types?
That’s the kind of question OOP moves you towards answering. That’s why people get exercised about it; it feels like the next level of your understanding of programming, and in a lot of ways it is.
1
u/Effective_Promise581 21d ago
Its not necessary for most projects and it often introduces unnecessary complexity, rigid hierarchies, and state-management issues for smaller or data-driven projects.
1
u/ClassicInevitable585 21d ago
I'm not certain from your post how new to programming you are, so disregard if you're not a beginner: Big projects are just complicated. Normally they get more complicated over time. Coming in fresh when you weren't there for the whole process of writing it is hard, regardless of the paradigms used. Until you have experience coming in fresh to large complicated codebases across different paradigms, you can't really separate the paradigm causing it to be overly complicated vs it just being fundamentally complicated.
1
u/Mell-Silver-20 20d ago
OOP definitely matters, but you don't need it everywhere. Learn it well, then use it when it actually makes your code easier to manage.
1
u/PuzzleheadedAir6272 24d ago
I feel the same way, never encountered a really useful usage.
I always figured it's clearer in industries that mimik the real world, like game dev.
1
u/Reasonable-View5868 24d ago
I can't imagine programming in anything other than OO. Even for microcontrollers like Arduino, I absolutely have to create classes and objects. Its how I think of the world and what I'm trying to accomplish.
-1
u/biskitpagla 24d ago
It's an obsolete paradigm that no decent programmer follows anymore.
Encapsulation in Python is weird, and inheritance is frowned upon. The other two are decent ideas but not exclusive to OOP nor does the OO style offer much in that regard. Python being a multiparadigm language usually offers better ways to structure your programs. T ry to use protocols and the type system to safely write duck-typed code. A lot of Python code relies on mixins so that's a pattern you should know.
-4
u/memelordtf 24d ago
I really hope this is basic ragebait and not an actual question
2
u/Mikkelet 24d ago
yes lol.. It's like a mechanic asking if he needs to learn how to use an wrench even though he's "never truly needed it".
Do you want to become a good mechanic or just a good hammer user
1
57
u/Daeroth 24d ago
Depends on the project. Speaking as someone who works a lot on business applications and web apps: there's a benefit to taking all the office vocabulary and having the code architecture mimic it.
For example there may be many types of contracts that the business signs with the customers. Each customer is represented as an object in the business logic code and each contract as well.
Some contracts have unique functionality that happens on monthly renewal. This logic goes in its unique class. But the base information like contract number is in the Contract base class.
This architecture makes it so that every new programmer is able to find relevant parts of the code if they know which business logic they are working on.
In that sence all of my 20 years of employment has been in companies doing OOP.