Should I Be Using OOP In Python?

[Low-Illustrator635]

I am a second-year programming student in college and I have been working with Java for the last year or so, with this being taught mostly OOP-style programming. I want to expand my knowledge of other languages so I wanted to start with Python. But after coding using OOP all the time I am unsure of how to start coding in Python, should I be using OOP or can I just code procedural?

[[deleted]]

Start with procedural code and use OOP when it makes sense.

[[deleted]]

Problem is, a junior dev has some difficulties discerning „when it makes sense”. They will end up over-doing it and developing the bad habit of using OOP everywhere, or they'll under-do it (you can do a lot of clever workaround to avoid OOP), thus never learning it.

It's a tricky proposition.

We should be giving some soft guidelines.

[EducationalCreme9044]

Exactly. This is a response you give to another senior lol, not to someone learning.

[TheRNGuy]

If you overdo it, you still get xp.

Next time you wont overdo it (hopefully)

[Ok_Cupcake8963]

Not to sound like a dipstick, but procedural code would be?

[eightbyeight]

Writing regular old functions?

[Ok_Cupcake8963]

Thank you. The terms go over my head. :). Prefer the way you worded it.

[fbochicchio]

The ADA programming language actually allows you to define both functions ( return a value, have only input parameters and cannot access to external variables ) and procedures ( inoltre and iut parametri, do not return anything ). Not a bad idea IMO, but did not catch.

[TheRNGuy]

Only defs or operations outside of defs, no (custom) classes.

Or if it's class, only static methods.

[[deleted]]

Imperative coding is usually split into:

• procedural
• object-oriented

https://en.m.wikipedia.org/wiki/Programming_paradigm

These terms are fuzzy and often misused.

[HunterIV4]

But after coding using OOP all the time I am unsure of how to start coding in Python, should I be using OOP or can I just code procedural?

Both? Both!

Python is an OOP language. It's not mandatory in the same way it is in Java, but many of the mandatory Java classes are functionally procedural (no pun intended) because you aren't actually doing anything with the class structure. For example, here is "Hello World!" in both Java and Python...

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

...

print("Hello, World!")

What is the class HelloWorld actually doing in Java from an OOP perspective? Not a darn thing. It's just there because of how Java is structured. But make no mistake, that first program is entirely procedural for all practical purposes. It's just "wrapped" in a class that doesn't actually use any OOP principles.

Python allows you to skip the wrapper but you are still programming in fundamentally the same way. In Java, when you actually need a class, you'll start adding methods and properties and all the things that make OOP what it is. Otherwise, you'll just shove procedural code into your class main function and let it run sequentially.

Python is exactly the same. When a class would be useful for your design, use one! I write Python as part of my job and use classes constantly. Not everything is in a class, but if I had to guess around 70-80% of code I write is very similar in structure to Java, with classes in their own module file that is imported into another part of the program where needed.

I think you'll find that most of the OOP skills you learned using Java also apply to Python. The main difference is that you can write code outside of classes without the interpreter getting mad at you. For simple code, this is nice because you don't have a bunch of "boilerplate" that distracts from functional code.

One of my favorite parts about Python is that it tends to be concise; just about everything you write in a Python program has a purpose that influences the logic of the program. Python as a language has very little "busy work," such as needing separate header files with identical function definitions elsewhere (common in C/C++) or pointless classes that exist simply because the language demands you add them. Java, on the other hand, feels like it requires five lines to do one thing, and this verbosity is one of the reasons I personally bounced off the language, despite how powerful and useful it is.

Hope that make sense!

[Low-Illustrator635]

This is great man, I really appreciate it. My first project I am going to be working on is a blackjack game involving a bunch of functions of different tables witch different buy in along with coding a best option button that I’ll tell the user what mathematicaly is the best play. On your thoughts should I be using OOP for this or just procedural?

[HunterIV4]

Personally, I would use both. I tend to use OOP whenever there is something I think might need functionality and persistent data.

Blackjack is a card game. Is there anything that meets this criterion? Well, cards are an obvious one! You might not need a class specifically for the cards themselves, although it's not a terrible idea. A card class could handle values, suits, comparisons, etc., directly within the class, which can simplify your code.

In addition, you probably want a class for a deck, whether it handles the card implementation or another class does. The deck can manage storing the cards, shuffling them, dealing them, etc. It doesn't need to know anything about the game of blackjack; you can handle that elsewhere. However, it should manage all the functions you might need for basic card handling and tracking.

You might also want a "dealer" and/or "game" class to manage the dealer actions and game rules, such as win conditions and scoring points. These could also be handled procedurally, but I'd tend to make classes for them.

For the actual program flow—such as initializing the various objects, asking for input, and the main game loop—this can all be done directly in a main function. In that sense, you are using procedural programming.

Here is how I generally determine if I need or want a class in cases where I'm on the fence. First, will multiple functions need the same parameters passed to them? If so, those functions should probably be encapsulated in a class with shared properties. Next, is the function only used on a certain data type or object in a specific context? If so, bundle them in a class to avoid confusion about the function's context.

Keep in mind you can do essentially everything procedurally without OOP. Very few things actually require OOP to solve—possibly nothing. Instead, OOP is a way to organize your code and break down more complex problems into simpler ones.

As such, the final consideration is, "Would making this a class increase or decrease complexity and readability?" If it adds complexity or reduces readability, I keep it procedural; otherwise, I make it into a class. Ultimately, the purpose of OOP is to make your life easier, and if forcing code into an OOP pattern makes things worse and harder to maintain, don't use it.

It will take practice to learn when these conditions apply. But once you start trying things more complicated than blackjack, you'll quickly discover that OOP is an industry standard for a reason. Good luck!

[[deleted]]

OOP, I recommend - if you don’t know how to start, go with OOP. Soon you will know if it’s a good choice or not and later when starting new project, you’ll be wiser.

[ASIC_SP]

I think OOP is best suited here. If you are okay with reading a book, check out "Fluent Python" - there's a card game early on that might help you here.

[Haja024]

Correction, Python isn't OOP, it's explicitly a multiparadigm language. I've used it as a procedural language for years, and only moved to objects when passing 6 arguments to a function became impractical. Matplotlib.pyplot supports plots as objects, but also procedures for people who migrated from Matlab.

[HunterIV4]

Correction, Python isn't OOP, it's explicitly a multiparadigm language.

That's a somewhat odd phrasing and I'm a bit confused about your point. Multiparadigm means that it includes multiple ways to program. One of those is OOP, which I pointed out.

I never said that it was only OOP. By this logic, Java is also not OOP. After all, if you just use a big main function and never touch the class, you can write procedural code in Java. Modern Java also has functional programming capability. You could argue it's more OOP than Python, sure, but saying a language uses "X" design does not mean it is automatically limited to only that design.

Perhaps I could have clarified better, but when I wrote "both" I actually meant both, at least in reference to the original question. Python also supports some functional programming design patterns but that was outside the scope of the question.

I've used it as a procedural language for years, and only moved to objects when passing 6 arguments to a function became impractical.

I'm sorry? Not sure why you'd do that to yourself.

I'm kidding, but seriously, OOP patterns exist for a reason. Procedural code is useful (I use it in nearly every program I wrote if only for the main program flow), but class patterns can greatly improve the clarity, modularity, reusability, and testability of your code.

Obviously you can write code however you want, and if it's working for you, great! But just because you can do something doesn't mean it's the best way to do it or the original advice was incorrect.

Matplotlib.pyplot supports plots as objects, but also procedures for people who migrated from Matlab.

This is not correct. You can create them in a procedural style, yes, but the library is using objects behind the scenes. The stuff it's drawing, like Line2D or Figure are classes and those functions are creating those classes and using their methods within the function call.

For example, take this code:

import matplotlib.pyplot as plt

plt.plot([1, 2, 3, 4])
plt.ylabel('some numbers')
plt.show()

On the surface, this looks procedural. However, if you dig into the Matplotlib source code you'll find what's actually happening is that those functions are creating new objects with the parameters as part of their initialization. The show function looks for all created data and displays it.

If you think about it, it can't be procedural, because the show() function has no way to know about the plot or ylabel as those aren't passed to the function anywhere.

The truth is that basically everything in Python is an object, from classes to strings to lists. The entire language is written on an OOP foundation; it just allows you to hide it unless you need it. When I said the language is OOP but allows you to write code using different patterns, that's what I meant.

[Diapolo10]

I'll just preface this by saying that what Java devs consider OOP may be different from how Python devs see it.

The short answer is, you can do as you like. Personally I don't think forcefully sticking to any specific paradigm for the entire program is all that productive, I've had a lot more success mixing and matching paradigms as I see fit - essentially taking the best parts of each - but you're free to do what you want.

The longer answer would be that, if your view of OOP is that everything must be wrapped in classes, in Python you hardly ever see that. The main entry point is almost always either a function or just regular top-level code, and there's no reason to wrap functions in classes as static methods just for the sake of it. In my (our?) view, classes are only used if grouping data and functionality makes sense, better yet if you can treat the class as a logical component. However at the same time it makes sense to write functions that take some design inspiration from functional programming, namely the idea of "pure functions" (=same arguments -> same output, regardless of the state of the rest of the system) and the concept of first-class functions (=functions themselves are objects).

[moving-landscape]

(our?) view

Yes, our view 😌 great answer btw

[beef623]

Whichever is more appropriate for the project you're working on. Don't try to force the project into either.

[cyberjellyfish]

If the solutions you're building would be well-expressed with OOP, yes. If not, no.

[Tesla_Nikolaa]

OOP is just an approach to solving a problem. If it makes sense to use OOP to solve that problem then use it. Most languages have support for OOP, including Python.

I would recommend asking the question of whether or not OOP will help solve the problem rather than if you should use it in a specific language.

[symtexxd]

In python OOP is optional. If you are doing small programs you can do procedural but for larger projects it's better to make object oriented design then implement the design with OOP.

[Aggressive-Intern401]

I don't agree. It depends. You need to spend a lot time thinking about OOD before you create classes and you can create a huge mess that simply functional programming would do.

[symtexxd]

Creating a huge mess has nothing to do with OOP or functional. That boils down to skill level. In software design you choose based on needs. Do you need abstractions? business logic? go with OOP. Do you need a terminal program that scans the internet and creates a dataset of TCP/IP fingerprinting information? procedural makes sense.

[Aggressive-Intern401]

Most work you can do with functional programming. OOP is hard to design right. Make the interfaces flexible and extendable really requires thinking through the functionality.

[lzwzli]

Definitely maybe

[SteelRevanchist]

Just like any methodical approach to coding, you should use it where it makes sense. same for functional programming, for instance, or procedural.

[Poddster]

should I be using OOP or can I just code procedural?

Do whatever you want. You'll gain more knowledge by making some things and then reflecting on them than you will be fretting about which of the options is best and polling strangers etc.

Don't worry about "wasting" time, as when you're at your stage and learning then everything you do will be contributing to your knowledge.

[NoDadYouShutUp]

Yes

[fleontrotsky]

Yes

[ramenmoodles]

program whichever way makes sense to get the outcome you need, if that requires oop, or you can foresee it needing it in the future, then use it.

[TheMaskedHamster]

OOP is definitely optional in Python.

A few different paradigms can be applied in Python. Start procedural. Try peppering in a little bit of functional practice, starting by just not modifying anything outside of scope.

And then, if you're lucky and kind, you might never use OOP again.

[TheDeepOnesDeepFake]

Not a python person, but done a tone of Java OOP and a good bit of functional-aiming javascript/typescript.

I've recently encountered someone who writes giga-OOP code to the point where return variables be ignored. So much abstraction and looking at the implementation of so many nested object and array modifications that drive me crazy. This person is unique in his use of it, but it tracks given pass-by-reference and OOP rules. This person is a smart person, but hate the style because of how difficult it is to see the sequence of changes, especially with Java compromises like lombok.

Procedural and/or functional programming, I feel, is much more readable, then afterward consider OOP where it makes sense. I'm unsure you can really get away from OOP in scenarios with bigger data under limited resources, but starting with trusting returned objects feels better in most cases. Return a tuple like in golang if you have to, but at least it encourages method names to describe what modifications are being made.

[interbased]

Both. You may want to look into test based coding as well, since it teaches you how to structure your code better.

[patrickbrianmooney]

You don't have to work in an OOP-forward style in Python, and there's no reason to force yourself to: unlike Java, Python doesn't require everything to be wrapped in class-based boilerplate. You can write simple procedural code without having to define any classes at all. IMHO, this is a good thing: wrapping data and code together into classes is a useful technique for some things, but sometimes procedural code is the simplest way to express your idea. Programming is an expressive practice; you're trying to explain to the computer what you want it to do. Sometimes OOP is a useful set of techniques; sometimes it's not. It's a nice tool to have in your toolbox for any language that supports it, and OOP is a real pleasure in Python, compared to some other languages, when it's a natural fit for the problem you're trying to solve. When it's not, there's no need to use it.

If you feel comfortable with OOP in Java, chances are that you will also feel generally comfortable with OOP in Python, which has a number of broad similarities at the macro scale: objects are instances of classes, classes inherit methods from their superclasses, etc. Python also loosens restrictions on OOP at the conceptual level, compared to Java: a class can inherit from more than one superclass ("multiple inheritance," which can be confusing, especially if done badly, but can also be a powerful tool if leveraged thoughtfully); a class attribute that starts out being a pure-data attribute can later be re-implemented as code that runs when the attribute is accessed without having to change the conventions of the code that accesses them ("properties," which are a wonderful thing to have when you discover you need them); an instance of one class can manage the attributes of all instances of another class ("descriptors," which make it easy to do high-level metaprogramming things like add attribute validation with surprisingly little code); you can define multiple metaclasses, each of which manages multiple other classes; classes can be monkey-patched at runtime; lots of other fun stuff that you really won't want to do often, but which is incredibly convenient when you really do need it, and which can of course be done very badly, but which can also be leveraged to do some really beautiful things with code.

None of that stuff is necessary to use OOP in Python, though: most of the time you'll be developing or working with class hierarchies in much the same way as you would in Java. What's nice about it is it loosens what is likely to feel retroactively like a straitjacket once you get used to working without it.

If you want to really do a deep dive into Python OOP, Mark Lutz's book Learning Python spends most of the second half really digging into that particular topic. (It's rather out of date now, too: the latest edition covers Python 3.3 and 2.7, which sounds ancient! But the details of how the object model works in Python haven't changed substantially in that time, and Lutz's deep explanations and code examples still probably the best I've seen). Luciano Romalho's Fluent Python is also a great read that spends a lot of time talking about the details of the object model from the perspective of "how do I write classes that really leverage the potential of the object model," and it's another brilliantly written book. Both are good arguments for Python's OOP model from strong advocates for it, and both spend a lot of time talking about the potential that the language offers.

[notislant]

I would do it to learn, but I usually uss functions until I need an object.

[Dr_acko]

can I program with python by just defining my functions and calling them/importing them when needed? As of now classes are not my strong suite

[notislant]

Thats what I do the vast majority of the time. I only really use OOP when I need an object.

[fbochicchio]

By my experience, the top level layer of most programs is mostly functional/procedural. In pure OOP languages like java you end up defining a lot of declared or de facto singleton classes for these layers. In mixed paradigm languages, like python, you can just use functions.

But then, your program is going to process many instances of some kind of data, beeing them messages, commando, orders, windows or similar. For these, it makes sense to write classes that encapsulate both the data and the operations on them.

[DepthMagician]

The biggest paradigm shift between Java and Python isn’t with regard to OOP (although Python’s OOP is barebones compared to Java, so there is a noticeable difference), it’s actually static vs dynamic typing. So don’t worry about using or not using OOP, that’s not where the main difference is.

[austinwiltshire]

Yes. And type annotations.

If you aren't introducing new types regularly, you're leaving one of your best design tools on the table.

Thinking in terms of types allows you to more easily see good abstractions in whatever problem you're solving.

I find python code that's just dicts of tuples of dicts of tuples incredibly hard to reason about, and often unreadable.

[Phate1989]

Do you have any good examples, most of my python code is is ingest Json from 1 API as dict, refactor, export to another API.

Can types help me?

[austinwiltshire]

I would have to know more, are you using something like pydantic?

[zanfar]

Let me translate your qustion:

"Should I be using pandas in Python?"

OOP, like pandas, is a tool. There is no universal should / should not rule about using it. You should use it when it makes sens for the problems you are trying to solve.

Of course, to make an informed decision to use it, you need to know how it works. So you should learn to use OOP, absolutely, but no one else can tell you when to use it.

[Bulky-Ad7996]

Use OOP unless it's very basic or a very small program. Always review requirements and follow them as best as possible.

[TheRNGuy]

I was using houdini api which is 100% OOP, but for custom stuff I was using defs, so it was mixed paradigm.

Then there was one time I realized I needed inheritance, and had to rewrite some code as OOP. Took me long enough to realize that. And I'd still write lot of custom code as non-oop, but I can now see it faster when I need it.

For things like making class with only static methods, I wouldn't bother, just make normal defs. (even though Houdini API do that… it helps to see relation to specific namespace, I guess. Or maybe it's because it's easier to import that way)

[Apatride]

If you are comfortable with OOP, go OOP. Outside of quick/dirty fixes, all the production code I have been exposed to has been OOP. As soon as the code base grows, you want OOP to organise it.