if classes are objects - why are they called classes ?
also, objects have attributes (size, shape, color) and functions (hammer is for nails, a car for transportation, a tree produces fruits...)
you can use objects in order to do something...products are designed for a certain operation, the fact they are designed means they a designation...
where is the correlation to classes ?
class Hammer:
self.size = "small"
self.shape = "hammer shape"
self.color = (50, 50, 50)
def drive_nail(self):
if nail.driven = False:
self.rect.y -= 20
okay i see,
so a class is really a description of an object, true ?
and still i haven't understood why is it called a class...
okay, now i got the meaning of class,
what i meant to say though, is that - usually when you define things (class or methods/functions) - the definition and functionality of things - is much more abstract... so how do you relate to abstract things ?
you really need to read on object oriented programming basics:
class basics
class - intermediate - inheritance
class - intermediate - operator overloading
brief example:
class Car:
def __init__(self, name, fuel, color):
self.name = name
self.fuel = fuel
self.color = color
def __str__(self):
return (f'{self.name} is {self.color} {self.fuel} car')
car1 = Car("John's_SUV", 'diesel', 'red')
car2 = Car("Jane's car", 'petrol', 'blue')
print(car1)
print(car2)Output:
John's_SUV is red diesel car
Jane's car is blue petrol car
class
Car is a blueprint of an object. As the name suggest it's a car and it has
name,
fuel and
color attributes/properties
The class Car is abstract definition of some thing/object. We can instanciate as many cars as we want, e.g.
car1 is red, diesel and has "name" - John's car
car2 is blue, petrol and has "name" - Jane's car
I've split thread, so that we don't hi-jack the other thread
okay, i will read it...
i'll try to explain better what i mean by abstract... :
when you have a car and its attributes - it is a physical object...you can think/imagine its attributes and functions...it's something you can touch...
but when, say, you have an iterator - how do you relate to an iterator ? how do you make the abstract - physical ?
when i relate to physical things - everything is understood, it's no problem...
when you make something abstract physical - you basically turn it into a machine, a machine you can relate to...with your senses...
i guess what i'm trying to say is - how do you bridge the gap between the abstract and the physical..
i hope you get what i'm trying to convey...
-----------------------------------
about the split, no sweat...
Some things in software don't have physical counterparts. They are abstractions that provide you an interface to do something useful in a program - like being able to iterate over some sequence in an efficient way, or performing operations against a database, for example. Abstractions are more about the what you can do, than the how. That even goes for abstractions we write ourselves - of course to implement them, we care about the how, but when we read code that uses them, we care more about the what.
But why do you think in terms of physical/tangible (i.e. something you can touch)? It's not different with the abstract concepts. I understand that initially it may be somewhat difficult, but it's no different than understanding the abstract concept itself. Actually understanding the concepts itself is the first step in order to model it, to describe it as a class. It's no different than understanding abstract concepts e.g. in school. Think of it as "thing" or "object" if you like (by the way in python3 all classes inherit from
object -
the base class for all classes). Think what attributes it has and are of interest of you. If it helps you may try to distinguish properties (i.e. the characteristics) and methods (what it can "do", actions).
I really don't know how to better explain it.
but programs are mechanical aren't they ?