[Tutor] Problems with references
alan.gauld at blueyonder.co.uk
Thu Jun 3 03:38:54 EDT 2004
> Alan....either we both totally agree but we cannot understand each
> other, or we have been going to two very different schools of
Possibly different schools :-)
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++
class A: pass
class B: pass
classes = [A,B]
instances = 
for cls in classes:
# create 5 instances of each
for n in range(5):
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
> blueprints on how the objects should be built, and these
> 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
And to manage the instances once created, if necessary.
> But of course all rules have an exception, meaning that sometimes it
> be necessary to have a class definition that never will be
> 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
> the name...Object Oriented Programming.
Absolutely. But classes are ojects too :-)
> To understand the difference between the class and object, we can
> one of the classic examples...a sail boat, or to be more precise,
> 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
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
> of modeling is the basic idea of OOP, and this modeling has as a
> 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
> 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. ]
Author of the Learn to Program web tutor
More information about the Tutor