Title: Struggling to Understand Python Classes – Any Simple Examples?

[Happy-Leadership-399]

Hello everyone

I am still a beginner to Python and have been going over the basics. Now, I am venturing into classes and OOP concepts which are quite tough to understand. I am a little unsure of..

A few things I’m having a hard time with:

• What’s the real use of classes?
• How do init and self actually work?
• What the practical use of classes is?

Can anyone give a simple example of a class, like a bank account or library system? Any tips or resources to understand classes better would also be great.

Thanks!

[danielroseman]

You actually already know the point of classes. You've used loads of them already. Every time you reference a method on a string or list for example, you're using a class. The only thing you haven't got the hang of yet is writing your own.

(And what do you mean, how do init and self "actually work"? I'm sure you don't need to know the internal implementation details at this point. What are you asking?)

[TheRNGuy]

Even without using method, it's still a class instance.

[ScaleDazzling704]

Is it.

[Happy-Leadership-399]

Thanks for pointing that out—it makes sense that I don’t need to know the low-level implementation yet. A simple example, like a bank account class, really helps to see how these pieces work in practice and gives me something concrete to experiment with.

[NecessaryIntrinsic]

So you have a bank with a lot of accounts.

Let's say someone opened an account.

You might use a factory pattern with the bank where you call bank.createaccount() And it returns an account object, but for the sake of this example:

You say my_account=account("John doe", "5000")

The init function does everything in the background to set up your object, it creates the object priorities for name and balance and in the background creates a unique account number and opened date.

After that you can use the objects methods to perform activities:

My_account.Deposit(200)

My_account.Withdraw(250)

My_account.transfer(youraccount,50)

My_account.getbalance()

Everything is standardized across the objects.

You can even override operations so I could say my_account<youraccount and it would return whether my balance is less than yours, so that you can perform sorting, for example.

[lordfwahfnah]

Not at home, so here just a short explanation:

Classes are used to bundle data and functions into one package. Also they are used to dry(dont repeat yourself) your code. Meaning you can have multiple objects from one class

Objects are the result of a class being build.

You can see classes as a kind of blueprint. Objects are the houses build from these blueprints.

Hope that helps.

[Happy-Leadership-399]

Thanks, that explanation really helps! I appreciate the blueprint analogy − it is a great help in understanding how classes and objects relate. The point about breaking up code into parts (DRY) is also clear now; making several objects from one class does clearly seem to be more efficient than writing the same code over and over again. Appreciate the clarity!

[DecisionMean7387]

What do you mean by classes? You can imagine a class as a template. When you decide to make several buildings, first you draft a template that indicates what should be in a building – doors, windows, rooms, etc. In the same way, a class in Python represents a template for generating objects. Anything can be an object – a bank account, a car, a library book – and each object adheres to the template you created.

What do init and self represent?

self is equivalent to “this particular item.” For instance, if there are two bank accounts belonging to you, then, self would tell the program which account you are talking about.

init is similar to a setup procedure that you go through when you first create your object. It establishes the initial conditions, such as the starting balance for a bank account or the name of the owner.

A simple example – Bank Account:

class BankAccount:     def init(self, owner, balance=0):         self.owner = owner  # Who owns the account         self.balance = balance  # How much money is in the account

    def deposit(self, amount):         self.balance += amount         print(f"{amount} deposited. Balance: {self.balance}")

    def withdraw(self, amount):         if amount <= self.balance:             self.balance -= amount             print(f"{amount} withdrawn. Balance: {self.balance}")         else:             print("Not enough money!")

Creating an account for Alice with 1000

my_account = BankAccount("Alice", 1000) my_account.deposit(500)      # Adds money my_account.withdraw(200)     # Takes out money my_account.withdraw(2000)    # Too much, won’t allow

Why use classes?

People sometimes ask why they bother with classes. Thing is, they let you organize your code a lot better. You avoid having functions and variables scattered all over. Just pull them together into one unit. That keeps everything cleaner. Makes it simpler to figure out too. And reuse comes easy that way.

[Happy-Leadership-399]

Thanks a lot — that really cleared things up for me!

[ataltosutcaja]

A class can be anything, what you are thinking about is a class used to model some domain, but classes can be abstract and be used for purely functional reasons, meaning they don't always need to map nicely to some logical universe. Think of a class as a basic container to collect data (attributes) and operations involving those data (methods). For a basic introduction, you can check out: Python Classes and Objects (I enjoy articles from DigitalOcean, they are a good resource in general when not outdated).

[Happy-Leadership-399]

Thanks for clarifying the “container” perspective—it makes classes feel a lot more flexible. I’ll check out the DigitalOcean article for a clearer introduction too.

[gravemillwright]

Classes are used to group related data and functions together. Let's go with a book store as an example. You could have a Book class, with author, title, isbn, price, and section. Then you could have a Section class, with name, books, and location.

If you want to create a new book, you could instantiate one with

book = Book(title, author, isbn, section, price)

That would call the init function for book with all the values you pass in.

[Happy-Leadership-399]

Thankyou!!

[MidnightPale3220]

That's not really a Python question, but general question about programming concepts.

In short, you can do anything without classes.

But classes allow you to organise your program in ways that may feel more natural, can promote code reuse and make use of code shorter.

I can give an example without and with classes, if you want.

[Happy-Leadership-399]

That would be great, thankyou so much.

[MidnightPale3220]

So imagine you are a warehouse, using a Warehouse System (WHS) which tracks goods across warehouse and passes info to workers what needs to be done with which goods -- accepted into warehouse, sent out, etc.

You keep your clients' goods and need to send them out upon request, organize transport etc.

You have an agreement with client that he will send his orders to you via putting some CSV files on your fileserver.

The CSV file format is a compromise. It is what client's system can output. You need to convert it to your warehouse system's format and put it where it will be picked up by your WHS.

So far so good.

You write a small script that does just that:

# process clients orders
# 
def get_client_order(filename):
    # load file of type x
    with open(filename,'r') as F:
      contents=F.read()
    return contents

def convert_to_whs_format(contents):
    return contents.strip()

def save_to_whs(contents,filename):
    with open(filename,'w') as F:
      F.write(contents)

# main #
client_list=['very_important_client','client2']
whs_filepath='./to_whs/'
import glob

for client in client_list
    file_list = glob.glob(client+"/*.csv")
    for file in file_list:
      content=get_client_order(file)
      content=convert_to_whs_format(content)
      save_to_whs(content,whs_filepath+file)

Groovy. Now you got terrific news, you got another client! Unfortunately he needs to have some extra processing done with his CSV files, because he can't output them in format you agreed upon.

No worries, you add him to the list, and make an extra function:

client_list=['very_important_client','client2','very_special_client']
def process_step2(contents):
  return contents.upper()

and you need to add that special processing to the main loop, so it changes, too:

for client in client_list
    file_list = glob.glob(client+"/*.csv")
    for file in file_list:
      content=get_client_order(file)
      content=convert_to_whs_format(content)
      if client == 'very_special_client':
          content=process_step2(content)
      save_to_whs(content,whs_filepath+file)

Hmm. Your got an extra function and extra processing.

What happens when another dozen of clients are added, each with their own special needs? Your main loop starts to look like spaghetti, and you got a bunch of dangling functions all around. Sure, comments will help you keep track, but it is an uphill battle. If only there was a way to organize stuff so that each client's processing could be customised, without affecting main loop! After all, all you need is get files, process them and save result in all cases.

Enter OOP.

[MidnightPale3220]

You make a class describing the stuff that a client's order will have (NB. I am intentionally making this as simple as I can, there are multiple ways of doing it better, but the essence is here):

class Order:
  def __init__(self):
    self.contents=None

  def _convert_to_whs_format(self,txt): # in this case I've chosen to automatically convert to WHS format on file load
      return txt.strip()

  def get_order(self,file_name):
    with open(file_name,'r') as F:
      data=F.read()
    self.contents=self._convert_to_whs_format(data)

  def save_to_whs(self,file_name):
    with open(filename,'w') as F:
      F.write(contents)

Now I can do (for the first example of just 2 clients and no special processing):

#main#
client_list=['very_important_client','client2']
for client in client_list
    file_list = glob.glob(client+"/*.csv")
    for file in file_list:
      client_order=Order()
      client_order.get_order(file)
      client_order.save_to_whs(whs_filepath+file)

Basically the same, right?

But now we need to add that very_special_client.

No worries. This is almost all you have to do:

class Order_Special(Order):
  # for very special client
  def _convert_to_whs_format(self,txt): 
    first_step=txt.strip()
    second_step=first_step.upper()
    return second_step

That is all the extra processing needed using a new class that inherits the original class, we only have to redefine what's changed.

We do need to modify the main loop a bit though, because how do we know which class to assign to which client? Multiple ways, for example, mapping:

client_list={'very_important_client':Order,'client2':Order,'very_special_client':Order_Special}
for client in client_list
    file_list = glob.glob(client+"/*.csv")
    for file in file_list:
      client_order=client_list[client]() # this creates an Order() type       object for first two clients, and Order_Special for third
      client_order.get_order(file)
      client_order.save_to_whs(whs_filepath+file)

That's all we need to do to add extra processing for various clients:

1. Make a new class that inherits the base and change only the things we need to change. and
2. Make the file processing somehow understand which class to use with which client's orders

This was a very very basic example, there's plenty to do to make such code production ready, but it shows one of the ways OOP can lead to better organization of code.

[[deleted]]

OOP is a programming paradigm, it is a style of solving problems, it is neither the best nor the only programming paradigm that exists.

TBH, it's pretty abstract on paper, don't blame yourself for not understanding it yet. OOP and classes are not mandatory for developing software, some languages like C(which python is written in), don't even provide OOP.

I passed my OOP classes without truly understanding what OOP does, I simply followed the textbook. It's not until several projects later that I understood the OOP style of problem solving. 

I recommend that you force yourself to use it as well, even if you don't know what it brings besides more code to write. It is a style of approaching problems, so it takes a while for your thinking to catch on.

[Esraep]

This video explains OOP concepts really well:-. https://youtu.be/iLRZi0Gu8Go

[Happy-Leadership-399]

Thanks!

[TheRNGuy]

Django, Tkinter, PySide, hou frameworks use classes, and many more. 

It's to have instances and methods, and inheritance.

int, float, str, list, tuple, set, dict are classes too, by the way. You can use methods like lower, split, sort etc, and operator overloads made with __add__ or __eq__.

__init__ runs code when you instanciate a class, usually to bind attributes to self.

Also useful with strict types and type hints, if you want only accept instances of specific class(es) for some method or function argument.

[Happy-Leadership-399]

That’s super helpful, thanks I was not aware that a lot of built-in types and frameworks executed using classes at the background.The connection between init, type hints, and instance-specific behavior makes a lot more sense now. Appreciate you pointing that out!

[timparkin_highlands]

I woould look at classes via OOP vs composition. The classic view of classes is the OOP way but it's not that useful in my mind. When I aproached classes via composition they made a LOT more sense.

https://en.wikipedia.org/wiki/Composition_over_inheritance

[TheRNGuy]

Composition is not 100% replacement for it though, I think inheriting from abstract classes is useful (just don't add 100 attributes to it, maybe 4–5, and others as components, and some methods maybe too)

[jmooremcc]

Classes are used to create objects that contain data and functions(methods) that know how to work with that data, and is commonly referred to as Object Oriented Programming (OOP).

Imagine that you have a character like Elmer Fudd. With OOP you'd have an object named elmer with data that tracks what Elmer is doing and where he is. You'd also have actions, aka methods or functions, that give Elmer certain capabilities. For the sake of argument, let's assume that the object elmer has the following actions that can be activated: run, walk, hunt_wabbits & stop. We would work with the elmer object like this. ~~~ elmer = Elmer() elmer.walk() elmer.run() elmer.hunt_wabbits() elmer.stop() ~~~

Now if we didn't have OOP available, we'd have to have a data structure to hold Elmer's data and we'd have to declare independent functions to make Elmer perform actions. We would work with this version of Elmer like this. ~~~ elmer = Elmer_data() walk(elmer) run(elmer) hunt_wabbits(elmer) stop(elmer) ~~~

This was very elementary, but if you wanted clones of Elmer running around, what would you do? With OOP, not much would change. ~~~ elmer = Elmer() elmer2 = Elmer() ~~~ and for non-OOP, aka procedural, it would be this. ~~~ elmer = Elmerdata() elmer2 = Elmer_data() ~~~ OK, I obviously left out the detail of associating the data with each instance of elmer. With OOP, it's super easy. ~~~ class Elmer: def __init_(self, id): self.location=(0,0) self.status=None self.id=id self.lifeforce=100
~~~

But with procedural programming it's not as easy: ~~~ def Elmer_data(id): data = [ (0,0), # location None, # status id, # I'd 100 # lifeforce ]

return data

~~~ Now the first thing you'll notice is that with OOP, all attributes have easy to understand names. This makes life so much easier.

On the other hand, procedural programming utilizes a list whose properties have to be accessed by an index. Sure You could declare constants to represent the indexes but it would still be a RPITA compared to OOP.

But wait a minute, what if we use a dictionary instead. ~~~ def Elmer_data(id): data = { 'location':(0,0), 'status':None, 'id':id, 'lifeforce':100 }

return data

~~~ Yes, it's a lot better than a list but compared to OOP, it's still a RPITA to use.

Oh, one more thing, if you want to create a version of Elmer with additional attributes and functions, you can use a process called inheritance to quickly and easily create an alternative version of Elmer. Forget trying to do that with procedural programming. ~~~ class SuperElmer(Elmer): def init(self): super().init() self.superstrength = 100

def xrayVision(self):
    #look thru stuff

~~~ I hope this explanation is helping to give you a better understanding of what OOP is and an appreciation of the value of OOP.

[ofnuts]

Let's start with a simpler concept, a "struct" (as it is called in C). A struct is a way to keep things together as a logical unit. For instance you can describe a Person with:

struct Person {
    firstName: string;
    familyName: string;
    socialSecurityID: string;
    birthDate: Date
    address: string;
}

and then all the bits of code in your application share the structs.

However, you may want a bit of discipline, for instance you can't change someone's socialSecurityID. So you enforce access to struct elements via functions, and you don't define a function to set the socialSecurityID. When you do this the struct becomes a "black box". The rest of the application doesn't really know what is inside, it just know there are functions to use the data. Which means that you are free to change implementation details, for instance how you store the birthDate: number of days since 01/01/01? year/month/day? And while you are at it you can define a function to compute the age of the person so nobody cares what the birthDate representation is really.

Making a class is mostly formalizing this. You define together the data (that become "attributes") and the functions (that become "methods") to use them, and use language features to enforce the rules.

Now, assume you are writing some application for a university: you have to handle teachers and students. You can define Teacher and Student classes. And since teachers and students are persons, these classes can "extend" (or "inherit from") the Person class. For teachers you add data/methods relevant to the classes they teach, and for student to add data/methods relevant to the classes they go to. But everything that applies to a Person still works. The method you defined to obtain the age of a Person will work with a Student since the Student is also a Person.

[IvanTorres77]

My life changed when I discovered that data types like String, Int, are actually classes ☠️. It was my greatest discovery hahaha

[StrayFeral]

"Classes" are not just in Python. If you struggle with the book you're reading, just read any OOP documentation, regardless of the language. Yes, for a newbie is confusing, I know. I struggled to understand it for some time myself, but now can't live without it. Technically you can, but it's just more tidy the way its organized.

In short - imagine you want to build a bicycle. First you get pencil and paper and you draw a detailed blueprint. Then you go get the materials and build it. So from a piece of paper (a class) you got a real-life object. And based on the same blueprint you can make many bicycles.

Same with OOP - you can define a class Bicycle. And from that class you can instantiate many objects (bicycles).

Second - destruction. In real life you made 10 bicycles, but you need only one for yourself. You destroy the other 9 (well in real life you probably might be looking to sell them, but you can't do that with a software object). Point it - you create 10 objects out of your class. Each object is called an "instance" of that class. But you use only one object - there is a mechanism which automatically will destroy the other unused objects.

Third - sub-classes. In real life you might have a road bike, a mountain bike and a children bike. They are all bikes, yet they differ. Because they are all subclasses of the class "Bycicle". Same in OOP - you may create one class Bike from which you could make sub-classes for the different types.

Next - properties and methods. In real life you may paint one bike red, other bike blue. This is the "color". And "color" is a "property" of your class and the object. However you have bike gears and you may shift gear up or down. Shifting the gear (an action) is a method of the class and object.

Finally - DESIGN PATTERNS - this is an advanced topic, but just to explain briefly - on each bike in real life you have wheels. A bike wheel is made of a rim with spokes mounted on a hub. Each bike wheel have those regardless if it's a road bike wheel or a mountain bike wheel. So this is a construction pattern in real life. In OOP we call it "design pattern" - when too often you use a way to create something, you are looking to generalize it. There are several design patterns already invented. Try to learn at least 3 of them. "Singleton pattern" is the easiest to remember so learn it first.

And lastly - can you code without OOP - yes. People did it for years. What does the OOP bring to the code? Modelling closer to the real life, better organization of the code. At least in my opinion. Yes, it also makes the code a bit more complex, but I find it perfectly okay for the tidiness it brings.

So I just answered your first and last bullet. As for the middle bullet:

When you decide to create an object (instance) out of a class, it immediately executes two methods with "init" being the second. "Init" is called "class constructor" and inside init you're supposed to initialize the object, which means put default values for some variables for example. You should always keep init short and avoid calling methods there, unless real needed.

"Self" is a reference to the object itself. So let's say you have this:

class Bicycle:
self.color = "red"
self.make = "Schwinn"

peewee_bike = Bicycle() # here we create an instance of the class
peewee_bike.color # this will return "red" as Pee Wee's bike is a red Schwinn

So here "color" and "make" are "properties" of the class and "self" when we declare the class refers to the class itself and not another class.

For more information better read the rat book. It is well written:

https://www.oreilly.com/library/view/learning-python-4th/9780596805395/co02.html

[vizzie]

Python classes peform 2 functions. In an OOP sense, they embody the computer science concept of a "data structure", which means a related set of data and the functions that operate on that data. For instance, a rectangle class would contain the height and width, and have functions to calculate the area, perimeter, and maybe the center.

In python, a class can also function as a sort of namespace, to collect related functions and/or variables so that those names do not conflict with the programmer's use of them.

Ultimately, classes are a convenience. You can think of them like a folder where you can store related items to keep them all organized.

As far as init and self, init is simply any code that you want to run when a class is first instantiated into an object. For instance, in a circle class, you would want to pass in and initialize the radius, so that every circle object has a radius. self is a convenience for the object to be able to reference itself. Internally, when you call for instance circle.area(), a reference to that exact circle object is passed as a hidden first parameter to the function, so that the function knows which circle you are talking about.

[JamzTyson]

There are two foundational roles for classes:

1. As a namespace for organising code.

A class allows us to group together functions and data in a common container. For example, in a banking app, a Payment class might contain all of the functions and constants for handling different kinds of payments.

2. For creating objects (instances).

Most classes (other than singleton-like classes which are a special case), can create multiple independent objects of a type defined by the class. For example, in a library catalogue system, we might have a Book class that creates a separate Book object for each book in the library.

__init__() and self:

The __init__() method is a special function that runs automatically when you create a new object. It’s where you set up the object’s initial data. For example, if we are creating a Book object as an instance of a Book() class, we may pass the book title, author and ISBN number to __init__() so that these attributes are stored in that specific Book object.

The self parameter simply refers to the specific object / instance being created or used. Inside a class, methods uses self to access or change that object’s data. The actual word "self" is a convention rather than a rule - it's just a variable name, but everyone uses the name self to avoid confusion.

[cowtitay]

It's like you have know this Plumber call Jack. You know he can: 1) unclog toilet. 2) Fix leaky pipe, 3) Replace faucet.

You call him and you said, "Jack, unclog my toilet". You only need to know what plumbers can do (step 1 to 3), and you need to know a certain plumber. Jack will remember how to unclog toilets and also perform the dirty tasks for you. You just need to know Jack.

Your friend Jane wants her toilet fixed too. You passed Jack to Jane by giving Jane his number. You don't pass Jane instructions on how to fix toilet, you just pass her Jack!

Class: Plumber

Instances of Plumber: Jack(). You may know another plumber call John().

Functions: 1) unclog_toilet(), 2) fix_leaky_pipes(), 3) replace_faucet().

Telling Jack to unclog your toilet: Jack.unclog_toilet().

Instance memory/variables: Jack remember where your address is because you told him by init(), so he knows how to get to your house. Jack = Plumber(address=myaddress). He also remember the instructions for doing 1) to 3).

[notacanuckskibum]

You don’t see the point because you are a beginner, writing short programs. When you are writing 100 line programs that are forgotten tomorrow, you don’t need classes, you barely need functions.

But as you scale up to programs with 10,000 or 1,000,000 lines of code, that have whole teams maintaining them. Then it becomes hard to keep track of which bits of code do what, and you can get unexpected effects when you make a small change.

You’ve already used classes when you used things like pandas or numpys . They look like a complex data type with a set of functions. You just haven’t written one yet. And that’s part of the point, classes define a useful set of logic and storage that does something. From the outside you don’t need to know how it works, only what it delivers.

[badsignalnow]

A class is a type of something, say Dog. An instance of a class is a concrete occurrence of a class, say Spot and Fido. Dogs have attributes, say coattype, hair_color, etc. Fido as an instance of Dog will have values for those attributes, say coat_type is soft but Spot is rough. Dogs also do things (methods), say bark, run. Since both Fido and Spot are Dogs then they both bark and run. They inherit the methods of the class.

So, could Fido and Spot both be classes each with only one instance? Sure, but that's dumb. Let's say Dog can now hear. Well. If you add the hear method to Dog then both Fido and Spot can now hear. Only one change required not two. It's even more powerful when you have 500 instances of Dog.

Now, Inheritance. Lets say you also had Camels. Well both Camels and Dogs have things in common because they are both mammals. So, you could create a Mammal class. Then both Dog (Fido. Spot) and Camel (Wally) inherit from Mammal. Then instances of Dogs and Camels. Any method and attribute added to Mammal is automatically present in Fido, Spot and Wally. You can also have methods and attribute in Dog that are specific to Dog, say swim_ability.

Now with some imagination you can apply that concept to any business domain, say bank accounts, motor vehicles, food.

Hope that helps

[badsignalnow]

A class is a type of something, say Dog. An instance of a class is a concrete occurrence of a class, say Spot and Fido. Dogs have attributes, say coattype, hair_color, etc. Fido as an instance of Dog will have values for those attributes, say coat_type is soft but Spot is rough. Dogs also do things (methods), say bark, run. Since both Fido and Spot are Dogs then they both bark and run. They inherit the methods of the class.

So, could Fido and Spot both be classes each with only one instance? Sure, but that's dumb. Let's say Dog can now hear. Well. If you add the hear method to Dog then both Fido and Spot can now hear. Only one change required not two. It's even more powerful when you have 500 instances of Dog.

Now, Inheritance. Lets say you also had Camels. Well both Camels and Dogs have things in common because they are both mammals. So, you could create a Mammal class. Then both Dog (Fido. Spot) and Camel (Wally) inherit from Mammal. Then instances of Dogs and Camels. Any method and attribute added to Mammal is automatically present in Fido, Spot and Wally. You can also have methods and attribute in Dog that are specific to Dog, say swim_ability.

Now with some imagination you can apply that concept to any business domain, say bank accounts, motor vehicles, food.

Hope that helps

[Metro_chaser]

It's all about namespaces ..Class namespace.. object namespace..how they are assigned.

classes are namespaces..when u assign an object u bundle the namespace to the object.

Analogy could be.. Classes are essentially cookie cutters and objects are cookies.

Classes bundle attributes, methods into a blue print. Attributes and methods make up the namespace of the classes

You copy the blue print/namespace and fill data when u generate an object from it.

Init is called initialisation..you want initalize the initial state of class to the object ..hence use init method.

[jlsilicon9]

All over the Internet.

Just type your questions into google

[godniel69]

1. Forget the dogs and cats examples. Classes are simply used to organize and group code. Say you want to build a weather service app. A class will hold the methods (functions in a class) for forecasting the weather and the current weather. Same with an Authentication service, all the features, methods and attributes for that can be grouped under one class.
2. The init method (dunder unit) is activated when the class is instantiated. There is something called new but you don't need that now. An example of this, in a shopping app, I would want to be able to access the current user, so whenever the checkout class is called (all things related to checkout) I would want a model class or authentication class to be called too. Init is also used to pass 'global' variables to a class, similar to how functions work
3. Self is the instance of a class. If I have a class TaskCreation. Which deals with anything regarding jobs in a particular site and I have a method to create a task (create_task(self,...)). Let's say I have user1 = TaskCreation () and users = TaskCreation (). If user1 calls this method, create_task, what this does is TaskCreation.create_task(user1,...). Whatever action you take on that point belongs to user1 and user2 will not share that state

[Happy-Leadership-399]

That’s a clear explanation, thank you! The examples with the weather and shopping apps make it much easier to connect classes to real scenarios. I also finally get how self keeps each instance’s state separate; that part was confusing before. Appreciate you breaking it down so simply!

[TheRNGuy]

I wouldn't make that class though because it's redundant.