[Tutor] Problems with references

[Martin Hjort Eriksen]

>Possibly different schools :-)
>
>  
>

We are... :)

Now it all makes sense to me, thank you very much. I had no idea that 
OOP also worked in that direction.

2 small questions if it is ok...

1. "self" is that a reference to the class or an instance of the object?
2. Since that there are different paradigms within the OOP framework, 
which one is the most "correct"? (I know it is a wierd question.)

/Martin

>What you are describing below is the fairly basic version
>of OOP as typically implemented in languages like C++/Java etc.
>It relegates the class to being a kind of cookie cutter with
>no interesting behaviour of itself. The longer you use objects
>the more you come to realize that this is an inadequate model.
>
>The early OOP languages (Lisp, Smalltalk, Actor etc) all
>recognised that classes had behaviour and attributes of their
>own. In fact in Smalltalk, where everything is an object, it was
>recognised that classes were objects too - they were instances
>of the class 'class'. (classes are objects, in the same way
>that functions are objects, in Python too)
>
>The purpose of class objects is amongst, other things, to act
>as factory objects. Thus constructors are class methods - you
>send the create message to the class, not to the instance
>- the instance doesn't exist yet!
>
>Similarly if you have a large collection of instances of a
>particular class which are not related to each other in an explicit
>collection, you may want to find out how many instances currently
>exist - that is something that the class knows - it created them
>after all... Another class responsibility would be to find a
>particular instance out of the pool of objects
>
>In a large database environment you may want to create an object
>from scratch, or to instantiate one from a database given an ID.
>The two different creation mechanisms are again the responsibility
>of the class. Related to this is the idea of type convertion,
>you may want to convert a piece of text to RichText, so the
>RichText class provides constructors that can take an ASCIItext
>object, a Postscript object, an HTMLobject etc.
>
>In a network application a process wants to send a message to a
>particular instance of a class, it can do so by directing the
>message to the class object in the receiving process which in
>turn locates the instance and forwards the message - acting
>as a proxy for all received messages for its instances.
>
>Languages like C++ implement class behaviour using static methods
>and attributes, which is an adequate if slightly inelegant way of
>doing so. Lisp, Smalltalk and Objective-C have explicit provision
>for class  methods. Python lies somewhere in between with similar
>implementation to C++ but with some of the extra capabilities of
>Smalltalk. For example you can create an attribute that refers
>to the class - you can't do that in C++
>
>For example:
>################
>class A: pass
>class B: pass
>
>classes = [A,B]
>instances = []
>for cls in classes:
>    # create 5 instances of each
>    for n in range(5):
>        instances.append(cls())
>
>for obj in instances: print type(obj)
>##################
>
>You can find some more about this in Guido's paper in the new
>type system and meta classes, but beware its a confusing read!
>Also the excellent book "Putting Meta Classes to Work" by
>Foreman and Danforth.
>
>  
>
>>As a starter, you have classes and objects. The class definitions
>>    
>>
>are a
>  
>
>>blueprints on how the objects should be built, and these
>>    
>>
>deifinitions
>  
>
>>are usualy not interesting when they are not instantiated.
>>    
>>
>
>Mostly that is right, except that the class is what is used to
>instantiate the instances...
>
>  
>
>>purpose of class definitions is to provide blueprints for the
>>    
>>
>objects.
>
>And to manage the instances once created, if necessary.
>
>  
>
>>But of course all rules have an exception, meaning that sometimes it
>>    
>>
>can
>  
>
>>be necessary to have a class definition that never will be
>>    
>>
>instantiated,
>  
>
>>where the different part will be called staticly.
>>    
>>
>
>But this is very rare and usually an example of bad design or an
>attempt to hide what is really a set of related functions
>- Java is rivven with this kind of horror.
>
>  
>
>>best OOP maner, this should be kept to a minimum. Well it even lies
>>    
>>
>in
>  
>
>>the name...Object Oriented Programming.
>>    
>>
>
>Absolutely. But classes are ojects too :-)
>
>  
>
>>To understand the difference between the class and object, we can
>>    
>>
>use
>  
>
>>one of the classic examples...a sail boat, or to be more precise,
>>    
>>
>the
>  
>
>>sail of a sail boat.
>>    
>>
>
>OK, Now consider that sail boat being an ocean going schooner.
>It has dozens of sales, including spares in case of accidents at
>sea. The captain wants to find a specific instance of sail
>- the pink one with green stripes, say. What object does he
>ask to find that instance? It could be the cupboard where
>the sails are kept, or ot could be the ship to ask all the
>cupboards - but it should also ask the masts since it might
>be aloft already - oh yes and maybe ask the sailmaker who
>is repairing a rip.... or he could just ask the sail class....
>
>  
>
>>Roughly the different states of a sail can be the
>>size, whether or not it is op or down, what color it is and so
>>    
>>
>forth.
>
>Yes, absolutely. And the different states of *the sail* class
>(as opposed to *a sail object*) are whether any sails exist,
>whether new sails can be created (the singleton pattern is
>usually most easily implemented through class methods!) etc.
>
>  
>
>>class. Multiple instances of the class, means different sails. This
>>    
>>
>idea
>  
>
>>of modeling is the basic idea of OOP, and this modeling has as a
>>    
>>
>basic
>  
>
>>idea, that the attributes should not be shared.
>>    
>>
>
>Absolutely correct. Instance attributes are unique to each instance.
>Class attributes are shared across all instances. For example the
>set of characters that may be permitted in a string object could
>be stored in the string class, rather than every instance having
>to carry its own copy around.
>
>  
>
>>This leads back to what it was that i origanally objected in one of
>>    
>>
>your
>  
>
>>e-mails, that the idea of attributes is that they should be shared.
>>    
>>
>
>And the difference between class attributes and instance attributes
>and the fundamental importance of the distinction. This is why I was
>so picky about it, thee is a very real but subtle difference which
>many newbie OOP programmers find confusing.
>
>[ It might help to have a play with a Smalltalk class browser
>- Squeak or Dolphin are free to download. There you can explore
>the built in classes and see the kinds of thing that smalltalk
>defines as class attributes and methods. ]
>
>Alan G
>Author of the Learn to Program web tutor
>http://www.freenetpages.co.uk/hp/alan.gauld
>
>
>
>
>  
>