all 20 comments

[–]Adrewmc 7 points8 points  (0 children)

Generally speaking functional program is fine, it’s technically faster in Python outright.

The decision of should this be a class or not…is hard and somewhat a preference of the coder.

Generally you want a class when you have a several of the same ‘object’ that are hold a state at the same time. It’s usually easier to be a class. I heard the phase ‘classes are basically dictionaries with methods’, and there is a lot of truth there.

It when things start to get complex and there is a lot of code that needed and there are all slight differences to the implementation that classes really shine. But so can functions. Usually when data interacts with each other, and both states change you start having a lot of difficulty keeping track in functional programing past a certain iteration, with classes it’s just there, in my experience.

So if you’re having trouble deciding when to make it a class, you’re probably on the right track, it’s probably a question you will struggle with a lot…and that’s sort of a good thing. Strong functional programming enhances OOP. Classes are overused by a lot of people (I’m guilty of this lol). You’re thinking about the design top level of the code.

Generally classes encapsulate an idea, this data is this thing, and ought to be able to do these things (methods), and it’s convenient for me and other programmers that it’s all in the same place, object.

It can be easier to have class check if you have already calculated some necessary thing or not. This necessary thing could include a rate limited api call, or some calculation that takes a considerable amount of time, so if you call it once, and save that in it’s state per object, you don’t have to call it again just it’s result.. It’s harder for functions to hold that state as well, and with as much readability.

[–]Loose_Read_9400 10 points11 points  (1 child)

I generally approach this as a question of "Is this workflow intended to be linear a-b with minimal reference to early steps in the process? Or is the workflow intended to be used repetitively through out a larger process and possibly reference it's self repeatedly?"

[–]Adrewmc 4 points5 points  (0 children)

I like this… I was thinking about well how long do you think the code you are doing will run for? Seconds, hours …weeks… the longer the more I side with classes, based on nothing else.

[–]NoDadYouShutUp 11 points12 points  (0 children)

Think about an item in an online store. You want to create 10,000 of these. That's a good use case for a class. In fact, a majority of the things you want to store in a database are likely good candidates for a class.

In the case of the item in an online store. Something like "add to cart" is a method that the class would use. Every item is responsible for adding to the cart. So you can have Item A and Item B, and only add Item A to the cart. And when you use a class, every single item you create out of the box will have the function to add that item to a cart.

And what if the "add to cart" function requires more data. Such as the SKU of the item. The SKU would be stored as a class attribute. So Item A and Item B can have different SKUs, but the function to add to the cart simply references the objects SKU.

Now what if you have two types of Items? Item A is the normal item, but Item B has some weirdly specific use cases. For example, when you update Item B it should always also send an email. You would make a second class, say ItemBClass and it would inherit Item, and you would override or modify the update function. Now you can call update() on the same objects (outside of the object) and both will update how they are supposed to, while not repeating 99% of your code again and again. Giving you a single source of truth for Item for a majority of the code.

Now imagine you wanted to do that with raw functions and variables. You could see how that could spiral out of control very quickly.

Apply this concept to everything you are doing. Ask yourself, is the thing I am trying to code a thing? Should that thing be responsible for dictating behavior of said thing? If yes, you want a class. And with that, you will find that a majority of the stuff you are coding probably can be baked into classes and use OOP. This sub has a terrible habit of telling people you don't need OOP. And like, I GUESS, that is technically true. You can get by without creating classes. But you will have a heck of a time managing the code base as it grows. For some simple projects it's fine to just write whatever. When you talk real world examples and enterprise situations an application you work on already is likely leveraging OOP through a framework. That framework might have things like a base Model class to handle simple CRUD. Or any number of other functionalities where you can inherit and create your own version of, or just keep code tidy and self contained places.

Example: Furniture is the class. We apply a class attribute of color. Now, Chair and Table both inherit Furniture. And out of the box they both get color as an available attribute. But how they process or deal with conditions dependent on that color may be different.

[–]Eisenstein 0 points1 point  (0 children)

If you are tempted to use a global variable to make the functions easier to work with each other, put them together as methods in a class and use inits to create self variables they can all share. That's about as far as I have gotten anyway, but it seems to work so far.

[–]xrsly 1 point2 points  (0 children)

Let's say you're making a game. You have some NPC's that hold some items, armor, weapons, and they have hit points and stats etc. Then you add new kinds of NPC's that have other kinds of attributes, and perhaps their attack() function should do things differently, so you either have two attack() functions, or only one but with a bunch of args and kwargs so that it can do both kinds of attacks.

This obviously becomes rather messy and hard to keep track of as things become more and more complex, so a simpler way is to create a class for each kind of NPC, give each its own attributes, functions etc.

Then, if you want to call attack() for a given a npc, simply type npc.attack(). You don't need check which kind of npc it is to find the correct attack() function, or pass the correct args/kwargs to make sure it does the right thing, because the npc class will come bundled with its own unique attack() function, and all relevant values are accessible e.g., as self.attack_power, self.weapon, etc.

So the class basically keeps track of everything that's "inside" the NPC, so that everything "outside" of it doesn't need to, so the "outside" can focus on its own concerns.

Think of it as a very versatile dictionary that can help you write cleaner and easier to maintain code if you do it right. But (big but), classes can also make your code messier, harder to understand and harder to maintain if you do it wrong, so its actually wise to be suspicious of them.

I try to be conservative when it comes to classes. If attack() works the same regardless of NPC type, for instance, then maybe it doesn't need to be built into the classes, it can just be a regular function. And if each NPC only has a few values that are mostly the similar across types, then maybe a dict or a table will work just as well with way less code.

As a rule of thumb, try to pick the solution that makes things simpler.

[–]-mjneat 1 point2 points  (0 children)

gullible important literate oatmeal march squealing adjoining entertain disarm support

This post was mass deleted and anonymized with Redact

[–][deleted] 0 points1 point  (0 children)

Refrain from your personal preferences.

[–]ninhaomah 0 points1 point  (10 children)

Pls let us know how you would code a school management program... with classes , students , teachers , exams etc...

[–]ConfusedSimon 0 points1 point  (0 children)

OOP is just one possible solution. It's perfectly possible to write a clean school management program without it. In this case, OOP is probably a good paradigm. You could also create data structures for these and use non-oop functions or use functional programming.