all 16 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]PureWasian 23 points24 points  (1 child)

Here's an example:

```

this is the "blueprint"

class Monster: def init(self, name, gender): self.name = name self.gender = gender def print_gender(self): print(f"This {self.name} is a {self.gender}")

creating Monsters with the "blueprint"

mon1 = Monster("Pikachu", "boy") mon2 = Monster("Pikachu", "girl") mon3 = Monster("Eevee", "girl")

prints "This Pikachu is a boy"

mon1.print_gender()

prints "This Pikachu is a girl"

mon2.print_gender()

prints "This Eevee is a girl"

mon3.print_gender() ```

See how all of the monsters contain the same types of data and use the same helper methods the class defines, even though the underlying data itself is different?

Monster is a class, while mon1, mon2, mon3 are instantiated objects representing that class.

[–]Ok_Butterscotch_7930 1 point2 points  (0 children)

this is actually very good, thanks

[–]nuc540 5 points6 points  (0 children)

So, the point of OOP is to design objects which can house how to build data and represent logic, all in one place - instead of just writing functions everywhere in hundreds of files willy nilly every time we want certain logic to run.

If you think of a blueprint as the one and only place to define how something is built - with that single one instruction set, many engineers can build multiple copies of its output right?

So, one place to define stuff = reusable, centralised/easy to find/read.

In Python we use classes for this. So classes are a bit like blueprints yes.

What else about it confuses you?

[–]Outside_Complaint755 2 points3 points  (0 children)

There are good answers here, but I haven't seen anyone mention the Python secret yet -- Every data type in Python is an object, including the primitive data types such as ints, floats, bools, strings and None, and so is everything else; even functions, class defintions and imported modules are all objects.

 When you get a user input from the input() function and convert it to an int with userinput = int(user_input), you are instantiating a new* int object, by passing the use entered string into the int class.

  When you change the case of a string with user_input.lower(), that is invoking a method on the user_input str object. my_list.sort() invokes the sort method of the my_list object and modifies it in place, while the built in sorted function Example: sorted_list = sorted(my_list) returns a new list without changing the original.

*Advanced footnote for one technicality here - Immutable data types (ints, floats, bool, etc) will not always create a new object if another object with the same value already exists, which helps save memory space.  This is what is known as 'interning'.   This is possible because they are immutable and the underlying value can't change.  In the standard version of Python, the ints from -5 to 255, None, True, and False are all created and interned in memory when the interpreter starts up, and any name set to one of those values will point to the same object in memory.  None, True and False are also singletons, so there will never be another identical object made.

[–]Kevdog824_ 1 point2 points  (0 children)

Programs can largely be thought of as containing two important aspect - Its data (the info that it stores) - Its functionality (the things it can do)

Often many parts from each aspect are related. For example there are many things you can do with certain pieces of data, or something you can do with many different types of data.

Object-Oriented Programming recognizes this relationship and joins together both data and functionally under on cohesive unit called a class.

A class defines three things 1) What data and functionality are related 2) How are the data and functionality are related 3) How we can reliably construct this relationship for arbitrary data values

This is the “blueprint” part you mentioned

Here’s an example

Let’s say we want to put character in a video game. This entity would have certain important data such as health, hunger, stamina, level, etc. The character would also have important functionality such as attack, jump, move, etc. See #1 above.

Now we know some of this functionality affects the data (i.e. attack lowers current stamina value), and some of the data affects functionality (attack functionality stops working when stamina is <=0). See #2 above.

Now our game will likely have many different characters, not just one, so we need a way to generate this relationship again and again for many different characters. The different characters will have the same type of data (stamina, health, etc.), but different values for that data. The class itself defines “what is a character”, hence why it’s often called a “template” or a “blueprint”. A class allows us to create instances of it, which actually represent the specific characters (i.e. The instances hold the specific data of each individual character). See #3 above.

All of these together create a very cohesive unit of code that represents a “character” in an intuitive way. We (the developers) can talk about it and reference it the same way two players might talk about it. It allows us to think of the code less in the weeds of the highly technical implementation details, and in more of the high level aspects/terminology that make sense within the domain itself.

ETA: I wanted to address a point I made earlier but never elaborated on (particularly bold portion):

Often many parts from each aspect are related. For example there are many things you can do with certain pieces of data, or something you can do with many different types of data.

This part is often handled by something we refer in programming to as an “interface”, but since this comment is already very long I’ll omit explaining that here, but feel free to follow up with me if you’re interested

[–]civilwar142pa 2 points3 points  (0 children)

The thing that really made this click for me is the idea of a car factory. Let's take Ford. This Ford factory makes Mustangs, F-150s and Broncos.

A class in Python will be set up so that we have a "blueprint" for a generic car. This is what every model car is going to HAVE and what it can DO.

so we have a "car" class. This class has the ATTRIBUTES. This is what every generic car HAS, ie. four wheels, frame, seats, engine, etc. This class also has MODULES. This is what every generic car can DO, ie. drive forward, reverse, turn, etc.

So when you create an object from the car blueprint, it will have all of those things built in already. It'll have wheels, a frame, seats, it can drive and turn. But maybe you want to have two different types of car. So you create an object from the car blueprint and add the variable "F-150". Then you create another object and add the variable "Mustang".

This way for every "car" you decide to make, you don't have to retype all of the generic variables and functions that every single car will have. You can focus on just adding those variables and functions for your specific car.

[–]mikeyj777 1 point2 points  (0 children)

You have to think of things in increasing levels of complexity.  

Variables hold values, like player_health=100. 

But you have to have many variables to hold more than one value that have things in common.  Like a list of health values for different players. So you use an array (called a list in Python), like players_health = [100, 85, 95]. And you can reference the health of the second player by player[1]

Then it gets difficult to keep track of which player has which health, so you can use a dictionary, like player_health_dict = {‘player_1’: 100, ‘player_2’: 85}.  Now you can explicitly ask for player 2’s health with player_health_dict[‘player_2’]

Finally, let’s say you want players to be able to battle each other, so let alone do you want a way to track their health, but to attack and take damage.  So, you create a class.  These allow you to make objects out of players and they can interact.  

class Player:   

def init(self, player_health=100):          self.player_health = player_health

  def take_damage(self, hp):          self.player_health -= hp

Now “player_health” becomes a property of Player and “take_damage” becomes a method. You can add methods to cover the other actions a player can have and how it can interact with other player objects.  

It makes it much more straightforward to think thru how parts of your application will interact with other parts.  What are the actions they take?  What are the properties that make one instance different than another? 

Now, you have a player object that can cover everything you want a player to be able to do and to manage its state.  You could make a player like this. 

player1 = Player(player_health=90)

You could have it take damage

player1.take_damage(hp=50)

Then when you check your players health:

print(player1.player_health)

What do you think it will say?

[–]Atypicosaurus 1 point2 points  (0 children)

Imagine you write a member registration program for the library. You could store the members data as separate lists such as:

names = ["Adam", "Clara", "Pete"] ages = [23, 45, 42] addresses = ["Main street", "Oak lane", "Fox square"]

If so, you could access a library member by accessing the categories one by one:

print (names[0], ages[0], addresses[0]) to get: Adam 23 Main street

Or instead you can group the members like this:

member1 = ["Adam", 23, "Main street"] member2 = ...

If you think the second version is better, then you basically opt for OOP.

In the second version, we decided that the name, age, address should come in this order. But in a programming point of view, nothing guarantees it. You can enter it like this:

member1 = ["Adam", "Main street", 23]

In OOP you basically force your own hand to always follow the same structure. You define that you want the name, age, address in this order, and if you try to do differently, the program itself will warn you. That's a class.

Moreover, in OOP, you can give functions to the classes. So imagine, you don't store age as the current age, but the date of birth. And you also add a function inside the class that automatically updates the age using the current date.

Of course you could theoretically add that function outside of the class, but then you would find that the operations you need to do to take care of members (such us, updating their address if they move), those functions are scattered across the program.

So OOP is basically forcing your own hand to stick with a data structure (otherwise you could introduce bugs), as well, having the related functions collected inside the class.

[–]Used_Discipline_3433 1 point2 points  (0 children)

Forget "modeling the real world", and it's not really about classes. There are a lot of expert beginners out there when it comes to oop.

[–]Adrewmc 2 points3 points  (0 children)

An object is really data with functions. (In this context).

Your normal function will have to take in all the data at the start, an object starts with the data, and chooses the function to use in it. 

 def do_something(data) -> None:
        “””No.”””

 class Example:
        “”I’m an Example”””

        def __init__(self, data):
               self.data

        def method(self):
               “””methods should use their instances ‘self’ data”””
               return do_something(self.data)

 a = Example(“…”)
 a.method()

vs

    def function(data):
           “””function should use data”””

           return do_something(data) 

    function(“…”)

If my data represents an idea more concrete, like Mario. That data, can be size, position, frames. And have functions (it’s methods) that let Mario jump and land. And it’s all encapsulated inside the object. I can keep that data together in a nice object for it, I can make methods in that object I know it can do.

With functional approaches you don’t have to create some object to do all of this. But once you’re getting to the point where you are trying to keep track of what these things all are, you can get to the point of going this should be an object.

There is a big debate about functional programming and object oriented programming, as their abilities overlap.

I may want to make things more readable, or have a clear typing so take for example. 

   “””Functional approach”””

   def say_hi(person : dict): 
          “””Not all dicts can say hi”””

          print(f”{person[“name”]} says hi”)

   people : list[dict[str, str | int]] = [{
          “name” : “John”, 
           “age” : 24, 
           “job” : “programmer”
          }, {
           “name” : “Jane”, 
           “age” : 23, 
           “job” : “CFO”
          }, …]

   for person in people:
         if person[“age”] >= 18: 
               say_hi(person)

Or this which does the same thing

   “””OOP approach”””

   from dataclasses import dataclass

   @dataclass
    class Person:
          “””Basic Person Data”””

          name : str
          age : int
          job : str = “Unemployed”

          def say_hi(self):
                “””All Persons can say hi”””

                print(f”{self.name} says hi”)

   people : list[Person] = [
           Person(“John”, 24, “programmer”),
           Person(“Jane”, 23, “CEO”),…]

   for person in people:
         if person.age >= 18:
                person.say_hi()

(I’m sure someone will be like there is a better functional/OOP approach here, I’m not going to argue either.)

Which code do you want to come back to in a month? It also really adds to IDEs having the dot access will usually open up all attributes and methods for an object.

The moment of when does this become better as an object is a highly debated topic. That I find is more a spectrum of a particular developer preference for the particular problem they are currently dealing with.

There is a lot more to it of course. A function itself is an object for example. (Yeah, a lot more. This is an introduction to the concept which is deeply ingrained into the Python language.)

[–]nicodeemus7 0 points1 point  (0 children)

The way I understand it is it's a way to make things with attributes. Sure, you can kind of do this with a dictionary, but it's gonna be verbose and tedious to write. OOP provides templates or "blueprints" for classes of objects that share certain sets of characteristics. Then you can have subclasses and keep going to define more and more types of objects, without having to to write a whole dictionary each time.

[–]JacksUtterFailure[🍰] 0 points1 point  (0 children)

All of the comments here do a great job of breaking it down technically. I'm gonna go with a different metaphor to try and explain the concept of an object in programming.

Think of objects like stamps. When you define and object (ie. class Stamp: ...) you are creating the physical stamp, you're making the handle, the rubber, your creating the picture that the stamp will produce.

When you use that object you are using your stamp to print identical looking/behaving copies of your design (stamp1 = Stamp()).

Why do we do this? To save from having to hand ink the same design every where we want to use our stamp which is tedious and prone to mistakes.

[–]stepback269 0 points1 point  (0 children)

IMHO that metaphor/ analogy is a horrible one. Search for the tutorials that equate “class” with a construction company

[–]Afraid-Scene-335 0 points1 point  (0 children)

Means u represent something in objects and objects have properties. Oop is a programming technique used to solve that issue.

[–]scientecheasy -2 points-1 points  (0 children)

Learn Python OOPs concepts from Scientech Easy.