[Tutor] Understanding Classes

[Christian Alexander]

I would first like to state two things, those being that I am a horrible
writer as well as explaining things, but Ill try my absolute best.
 Everything python is an object.  Strings, integers, lists, so on and so
forth.  In regards to classes and their relativity towards objects, I am at
complete standstill.  However, I understand that classes are parallel to
that of a blueprint, but that is unfortunately where the buck stops.

On Sun, Jan 19, 2014 at 6:50 PM, Alan Gauld <alan.gauld at btinternet.com>wrote:

> 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
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>



-- 
Regards,

Christian Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20140119/8892cc45/attachment-0001.html>