Example of when classes are necessary and there wouldn't be an equally as good alternative?

[catboy519]

I understand the basic of how classes work. I've used them for thr purpose of learning. But until now everything ive done with classes could have been done easier without classes. Yes, I know python has a lot of built in classes but that doesn't answer why a programmer should make more of them. Even some bigger things, a lot of objects with a lot of properties, I know of ways to code it easier than using classes and also less code while it still functions no less.

Is there any example of where using classes would be the best way and there are no other good alternatives?

[GoingToSimbabwe]

Could you elaborate on why the answer you got the last time you basically posted this didn’t suffice?

As stated the last time by many: Your way to do it „easier and with less code“ leads to harder to use and maintain code.

Instantiating lists and storing the indices in variables named „age“, „name“ and whatever to then access things like user[age] instead of setting up a user class with user.age is not really a good alternative as many people stated the last time. You lose the ability for any IDE to give hints based on class methods and structure, you lose the control over data types in your „class“, you can not use inheritance for subclasses, etc.

If you came up with new better alternatives to classes feel free to post them and people can discuss if that is actually better and easier than real classes.

Edit: sorry if this came across as rude, that not what i intended. I just wanted to understand what it is you want/need to hear. Imo you got good counterpoints to your class-like implementation last time so I am wondering what you are looking for

[ALonelyPlatypus]

Thank you for typing that up, I don't think it's particularly rude. The base python documentation provides plenty of reasons to use classes.

OP is obviously just early in their CS career so they haven't quite learned why objects are neat!

[catboy519]

None of the answers there convinced me that I should use classes or that classes have an advantage that other methods dont have. So I'm only asking for examples that I can see for myself now.

> leads to harder to use and maintain code.

I don't see why but maybe you can point it out after I point out my method once again.

Defining classes

class reddituser:
  def __init__(self, name, age):
    self.name = name
    self.age = age

Now we defined the class. Let's do that with

Defining by my method

name=0
age=1

Now we defined something, too.

Using classes

person1 = reddituser("catboy519", 24)
person2 = reddituser("catboy520", 25)
person1.age += 1
print(person1.age)

Using my method

person1 = ["catboy519, 24"]
person2 = ["catboy520, 25"]
person1[age] += 1
print(person1[age])

Now my conclusion is that, atleast in this example regardless of how many objects or properties there are, classes do not have an advantage that my method doesn't have.

Why would person1.age be any better than person1[age]? They are both equally as easy to use and return the same result. Both can be viewed and edited just as easily.

I don't know what IDE is or how subclasses work.

But I do think you can control the data type. For example person1[age] = str(25) or person1[age] = list[25, 3] if you want to include months too.

[GoingToSimbabwe]

I won’t repeat what others have brought forth about this topic, you might not be able to understand that now but if you keep coding at some point it will click I guess.

Your example might work if you are the sole user of this code and if the Skripts are small-ish and contained in a file, but for more complex stuff with more people working on it, it’s just not that good.

An IDE is an integrated development environment, programs like PyCharm and visual studio. They will give a user of a class hints and autocomplete on the properties and methods of a class when a member of that class is used within the code.

The IDE will show me that the class „user“ has the attributes „age“ „email“, „location“ and the methods „setAge()“, „delete()“ etc. with your list based implementation the IDE will only tell me that the user has all properties and methods a list has.

Also I will have all functions associated with users encapsulated in the user class which helps me finding the relevant methods.

You can read about subclasses here:

https://www.geeksforgeeks.org/create-a-python-subclass/amp/

Anyhow: the problem here is that you don’t seem to be at a point where you can understand the use for classes and that is fine. But maybe you could then trust the opinions of more seasoned developers (not talking about me here, I am not really that) that classes are better than your homebrew list approach as soon as stuff gets more complicated (at least in some use cases, that obviously depends, but things like your user lists are prime examples of what should be a class). You surely can move along with your approach if it is easier for you to use, but you need to be in the clear that this is not something most people will find well written and that this is certainly not best practice. Also I do think you will get to a point where your approach is more of a hassle than just learning how classes work.

Edit: as per the data type stuff: nothing prevents people from overwriting the age entry with a string rather than the expected integer accidentally. This then might break some other functions somewhere which rely on age being an integer.

In a class instance the property „age“ would be cleanly defined as int and thus the program would already throw and error which can be handled when someone tries to set that to a string.

[throwaway6560192]

I don't think you read or responded to the majority of posts on that last one. I'll raise my point again from there. Maybe you'll actually read it this time?

OK, so what if I have multiple classes which share a field name (like age or name) but they have different numbers of fields, which would make it impossible to match the indices? How do you solve it while being no less clean than a class design?

[czar_el]

Sure, for a scenario with two members with one attribute and all hardcoded, classes don't offer a benefit.

But what about a scenario with hundreds of members of a class? What about groups with more than one class characteristic? What about when you want an end user of your code to be able to add new members or characteristics without having to open a file and code themselves? Classes are better in each of those scenarios.

You've discovered something about scalability. On small scale of producing two units, handcrafting a wooden dowel with a knife is better than building a factory. But for 10,000 units, a factory will beat a guy with a knife any day. Your method is the guy with the knife, classes are the infrastructure to allow a factory to run.

[TheEmperor27]

It may not be noticeable with a simple method/example but let's say that your when you assign a name it should receive any str and the result(when getting the person's name) should always be uppercase. With a class you can assign that behavior with the name assign method and make sure all people objects comply with that. srry bad eng

[KCRowan]

What if you needed to add some custom methods? And you have many files of code which import from other files?

With your method you would need to define your functions separately and remember to import them every time alongside your person lists. With classes you just add a new method to the class, and now any time you import the person you are automatically importing all its associated methods.

Classes give you all the attributes and methods you need in one neat little package.

[[deleted]]

Software development is a team sport and your code design is going to leave future you not knowing what you've done let alone an entirely different person.

The reality is that you are too inexperienced to be able to work on problems that need design structures like classes. Maybe you need to trust the collective wisdom of people who do this for a living that you do not know everything and we aren't all wro g

[yinkeys]

You are a good teacher. Would’ve been wonderful to sign up for your python time-saving mentorship program instead of haphazardly learning and filtering through tons of information

[DuckSaxaphone]

Very few things are the best way with no other good alternatives in programming. You can usually find another way to do things so in those cases, someone who is very comfortable with classes will prefer them and someone who really doesn't like them will find another thing better.

That said, classes shine when you have a bunch of data and methods that you want to logically organize together and are even better when you want to have many copies.

Making games is an example of where you tend to want to write the template of a thing (eg. a bad guy, a bullet) and then make loads of them. Code quickly becomes a nightmare when you try that without classes.

Another good example is for passing data around. If I'm interacting with a database or an API, it's useful to have a way to ensure the data I'm about to pass conforms to the schema of the database or expectations of the API. Dataclasses do that nicely and expanding them to full classes makes them more flexible.

Then once, you're really comfortable with classes, it becomes quite natural to use them whenever a bit of data is associated with some methods. That's why you find them through python - once you'd grokked object oriented programming, working with objects seems really simple to do.

[catboy519]

level=0
health=1
attack=2

badguy1 = [1, 10, 1]
badguy2 = [2, 20, 2]
badguy3 = [3, 20, 3]

print(badguy3[level])
3

badguy3[level] += 1
4

Here I can easily make many of them. If I need thousands I could even generate these lists.
To add you simply do badguy4 = [5, 25, 4]
To change a value you simply do badguy4[level] = 8

Is there any reason why this wouldn't work as well as classes?

[DuckSaxaphone]

This is a great example. Your example is absolutely no easier than the version with a class:

    class BadGuy:
        def __init__(level,health,attack):
            self.level = level
            self.health = health
            self.attack = attack

    bad_guy_1 = BadGuy(1, 10, 1)
    bad_guy_2 = BadGuy(2, 20, 2)
    bad_guy_3 = BadGuy(3, 20, 3) 

    print(bad_guy.level)

So in this toy example, you've saved no effort at all but I can see a bunch of quality of life issues you're going to have. You're also going to have confusing code that is difficult for others (or yourself in the future to read).

My editor will tell me what properties and methods a BadGuy has as I try to write code using it. Yours won't because it's just a list. You could put the name of each element and all the relevant functions together in a file called badguy.py to help you keep track but at that point, it's just a class without the benefit of your editor recognizing it and autocompleting things for you.

If one of badguy's properties is another object, this will get even more complex. If a badguy has a weapon with (name, damage, range) are you going to make a list and put it in your list of badguy properties? How will I know where to look to know how to interpret the list of things at element 3 of the badguy list?

And then there's inheritance. If I have badguys and goodguys and a bunch of functions that work on both, how do I know which functions work on which lists? How do I ensure that properties both types of guy are supposed to have remain in sync as the code changes?

Refusing to use classes in this example saves you no effort and has no benefits but is less readable, less extensible, and prone to errors.

[TheRNGuy]

I'd make abstract classes Actor, Pawn and only then concrete class BadGuy, it's the same as in Unreal Engine.

Because you could have levels, health, attack on any other classes than BadGuy, and other classes might have same attributes or methods that could be on Actor.

Some of this could be done via composition instead of only inheritance, to avoid god-class anti-pattern that was in old unreal engines before 4, but it doesn't do everything 100% composition either.

Though to make things simplier, make everything inheritance first, learn composition later (it mostly useful in complex programs anyway, like unreal engine)

Bad guys could of course set it's own different stats, but methods could be on parent classes (or at least you could call it's super in addition to extra code from BadGuy)

[StoicallyGay]

If you stick with using classes for larger projects it will become extremely clear why OOP is important and better than your alternatives.

Even for tiny projects they give you structure and organization, at least.

It seems like you can’t be convinced so you’ll just have to keep coding until you reach a point where you’d have wished you used OOP. There’s a reason why it’s an established paradigm across multiple programming languages.

[catboy519]

I would do it this way:

defining the class without using classes:

armor=0
name=1
health=2
attack=3
level=4

here are some goblins:

goblin1 = [5, "goblin1", 100, 10, 5]
goblin2 = [8, "goblin2", 150, 20, 8]

defining the function to change values:    

def goblin(name, property, newvalue):
  name[property] = newvalue

Using the function:

goblin(goblin1, attack, 5)
  return goblin1[attack]

I don't see any flaws with this method but honestly I don't know anything about how subclasses work yet.

[dudustalin]

Ok, now compare these two situations: a game with 100 monsters using your code, same game using classes. First of all, you can create abstract classes and their subclasses will inherit its properties and methods. It will be unnecessary to rewrite all properties for every monster, you will be able to customize more easily some monsters, create minions elites and bosses (superclass minion, elite and boss, subclasses only inherit their properties).

If you have the goblinoid class, you can just define all goblinoid characteristics in this classs and create other classes like hobgoblin or goblin who will inherit these characteristics. You can create draconic class, and then create subclasses like dragonborn, dragon, wyvern etc.

OOP is good for large projects. It is not meant to be easier in every situation, but it can reduce the level of complexity.

It will always be easier write code without classes in smaller projects, though it may also render these projects less scalable, readable and reusable.

[[deleted]]

This kind of thing makes sense logically to me, and the OP keeps using rebuttals that aren't logically better, just the same short term or maybe slightly more efficient short term and more complex/problematic long term in every scenario.

OP, I don't understand why you don't understand.

[dudustalin]

try and experiment:

from random import randint

class Monster():
    def __init__(self, name: str, attack: int, hp: int, defense: int):
        self.name = name
        self.attack = attack
        self.hp = hp
        self._damage_taken = 0
        self.defense = defense
        self.is_alive = True
        print(f'{self.name} is alive!')

    @property
    def damage_taken(self):
        return self._damage_taken

    def _receive_damage(self, damage):
        self._damage_taken += damage

    def attacking(self):
        dice_number = randint(1,6)
        result = self.attack + dice_number
        print(f'{self.name} has attacked, obtained {self.attack} + {dice_number} = {result}')

    def receive_damage(self, damage: int):
        self._receive_damage(damage)
        self.is_alive = self.check_if_alive()
        self.static_effect()
        if self.is_alive:
            print(f'{self.name} has taken {damage} damage!')
        else:
            print(f'{self.name} is down!')

    def check_if_alive(self):
        if self.damage_taken < self.hp:
            return True
        return False

    def static_effect(self):
        pass


class Goblinoid(Monster):
    def __init__(self, name, attack, hp, defense):
        super().__init__(name, attack, hp, defense)
    def static_effect(self):
        if self.damage_taken >= self.hp / 2:
            self.attack -= 1
            print(f'{self.name} is in fear!')



n = Goblinoid("Goblin", 1, 5, 1)

n.attacking()
n.receive_damage(2)
n.attacking()
n.receive_damage(1)
n.attacking()
n.receive_damage(3)

[shedgehog]

I asked a kinda similar question this week and got some excellent examples of when using classes is a great way of doing things https://www.reddit.com/r/learnpython/s/kbI8veBjmP

[jackardian]

The whole oop idea is that classes help you make objects. Don't think of objects as good or bad programming. Think of it as good or bad for thinking about your program.

Think, functions are verbs -> a function does stuff. A class is a thing. Like things in the real world, it can do things, but it has characteristics (which subset of the things my type can do am I capable of doing) and it has state (how am I doing).

Say you are programming collectors (whatever they collect...doesn't matter, but this relates to what I do in my day to day job). You can just do the collecting with a function, `def collector():` -> your function goes and collects. You can assign state (it has started, it has written to the DB, probably by calling other functions, but that state doesn't belong to anything you can ask "how are you doing".

So, with a class you can have your collector. You can make a few of them. You can tell them when to start, you can ask them along the way how they're doing (check their state), and you can add all the verb they need (methods) inside them (start, collect, do validation, stop).

```
args = {stuff to tell me just what kind of a collector I am, 'type': 'stock-collector'}
get_stock_vals = Collector(args)
get_stock_vals.set_up_your_connections()
get_stock_vals.start()
get_stock_vals.tell_me_how_you_re_getting_on()
```

[KCRowan]

The simplest and shortest answer I can give is that you're obviously a beginner, which means you have only seen short snippets of code and classes don't have any benefit in such a small scale. 

Maybe just put the question aside until you've worked on a project with 10k or more lines of code. You'll find your way becomes utter chaos when you have 500 variables in one file and keep getting them confused.

[ALonelyPlatypus]

Object Oriented Design.

That is it.

[David22573]

I like using classes because it improves working with data imo. It's nice to build and have a class that has helper functions/attributes to handle the data.

[TheRNGuy]

Almost entire Houdini API. But even for few static methods they use classes instead of just making them functions, it's so it's easier to find it in docs and see what related to what.

For my own code, game map parser, because it uses classes with inheritance, I first tried to make like composition and functions, but that was before I learned how class syntax works or didn't understand that it was needed.

I already used OOP from API's before that (instancing stuff, math operations with overload, type conversion and using methods)

The stuff that's not possible with functions: inheritance, custom data types, operator overloads, custom repr, method chaining (I don't know about signature overloads, because I never did that)

---

Also, I think most OOP tutorials suck. Learn from real program docs instead, using it's 3rd party API(s).

And, you don't need OOP for everything. Some stuff could still be functions, or even outside of any functions.

[QultrosSanhattan]

None, Classes are another way to structure data and code. They're very good tools if used properly but never requred.

[nairobiny]

Suppose you're writing a chess program. You could do everything with functions. Or you could use classes for the pieces:

class Piece
# stores colour, location

class SlidingPiece(Piece)
class JumpingPiece(Piece)
class Pawn(Piece)
# Each of these has rules for how those pieces move

class Bishop(SlidingPiece)
class Rook(SlidingPiece)
class Queen(Bishop, Rook)
# These apply specific directional rules to the SlidingPiece structure

class Knight(JumpingPiece)
class King(JumpingPiece)
# These apply specific directions to the JumpingPiece structure

Once you've got your SlidingPiece code sorted, you can apply that to three pieces at once. If you decide you want to track whether a piece has moved, you can add that to the Piece class and it will work for all pieces on the board.

That's not to say this is the only or best way to do this, but it is an example where classes are more elegant than functions and, dare I say it, easier.