[Tutor] Understanding Classes

[Alan Gauld]

On 19/01/14 21:59, Christian Alexander wrote:
> Looked all over the net for class tutorials
> Unable to understand the "self" argument
> Attempting to visual classes

If you read my OOP tutorial there is a section there specifically about 
self.

And the v3 tutor includes an introduction to the formal visualisation
technique for OOP called UML. The diagrams illustrating the designs may 
help.

http://www.alan-g.me.uk/l2p/tutclass.htm

> I have searched high and low, for easy to follow tutorials regarding
> classes.  Although I grok the general concept of classes,

Do you also grok the concept of objects?
Classes on their own are fairly useless (unless you are using Java)
it is only when you create a universe of objects from those classes that 
they become useful.

If you can repeat to us your understanding of classes and their 
relationship with objects that will help us understand your
level and shape our responses accordingly.

> to visually understand what exactly "self" does, or why it is even
> necessary.  It seems very "magic" to me.

When you define a class you define the data (attributes) that
the class instances will have. Each instance will have a copy of the 
data defined in the __init__() method.
You also define a set of operations or methods that are associated
with the class. Those methods are shared by the instances.

Note the difference. Instances get a copy of the attributes
but they all share the methods.

Thus when you invoke a method on an instance the instance relays that 
call to the class. For the class to know which instance is being 
operated on, and for the method to be able to access the correct 
instance's data it needs a reference to the instance. That reference
is typically called 'self' or 'this'. (In some languages it's fixed
but in Python self is only a convention, you can use any name you like).

You can make the call to the class explicit and it will still work.
See below:

# define a class
class MyClass:
     def __init__(self,x): self.x = x
     def myMethod(self): print(self.x)

# create some instances
ObjA = MyClass(2)
ObjB = MyClass(4)
ObjC = MyClass(6)

# send some messages/call methods
objA.myMethod()       # call from the instance
MyClass.myMethod(ObjB)  # call explicitly to the class
objC.myMethod()      # direct again

All 3 calls do the same thing except the middle one
passes the object identifier directly to the class
whereas the first and last both do that internally
within the object structure.

> difficult with the "__init__()" method in classes,
 > and why that is also required.

It is not *required* as such. You can create a class
without an init but it's unusual.

When you create an instance of a class it creates a
data structure in memory referenced by the name of
the instance. But that structure is empty, it has
no data. So to populate the data for the instances
you must initialize it. That's what __init__() does.
It takes the arguments you provide and applies them
to the instance along with any static data definitions
you may define.

In the example we create an instance variable, x,
within the instances and assign the value of the
argument passed to init. Like any other method the
actual code lives in the class so we could initialize
it by calling init like so:

MyClass.__init__(objC, 66)

which is almost the same as doing:

objC = MyClass(66)

The difference is that the first case requires the object ObjC
to already exist, the second example creates a new instance and
then calls init on that instance.

> Keep in mind that I am a visual person (maybe I should have
> been a graphic designer), therefore most programming concepts flow
> irritatingly slow for me.

Most programming concepts have visual representations,
its just that program code being text tends to lead programmers
to be verbally based. But algorithms, state machines, logic, data 
structures, GUIs, formal requirements and OOP all have well
established visual representations, and in many cases they
are formalized so that, with the right tools, you can
create code purely visually.

If the above doesn't clarify things, and I suspect it won't
entirely, then please do express your understanding so far
in your own words and we'll try to clarify things from there.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos