[Tutor] Problems with references

Alan Gauld alan.gauld at blueyonder.co.uk
Wed Jun 2 14:54:20 EDT 2004

> >Nope, that is a basic tenet of OOP. The only language dependent
> >feature is how class attributes are implemented. For example
> >in C++ and Java they are prefixed with ''static',
> >
> But I do disagree that the basic idea that attributes should be
> across objects.

Class attributes are shared by definition, thats what makes them
class attributes - they belong to the class rather than the instance.

> The basic idea of objects, is that they can take different states.

Absolutely but objects  are not classes. (Although classes are
objects but thats getting too far into meta theory for this list
I suspect!) Instances have their attributes and they are unique
to the instance. Classes have their attributes andthey are
unique to the class and shared by the instances of that class.

If that were not true basic OOP would not work since OOP relies
on the ability to create instances which utilises the class
constructor which in turn is an attribute (or more specifically
a method) of the class. Indeed all methods are attributes of
the class shared by the instances. (Python is one of the few
OOP languages which allows you to define attributes in the
instances which are not in the class, but again that's verging
into the esoteric)

> These states are described through the attributes that
> the object has. This requires that the attributes are not shared
> instances.

[irrelevant aside: In fact it doesn't, it can be represented by
a single state attribute (which in turn can be stored by the
class itself). Some early OOP languages investigated such an
approach but it was very inefficient. ]

> But in some cases it is necessary that you have the ability
> to share attributes, but that should be rather rare,

In practice, in most large scale systems there will be class
attributes around somewhere, and indeed in Smalltalk it is
common practice to define a few class attributes for almost
every new class. In any system where persistence is implemented
(storing objects between program invocations) it is common to
implement class attributes and methods to manage the instances
(keep a count or object pool/cache for example, or to implement
an object search mechanism). However, I do agree that classs
methods are far more common that class attributes.

> practice is that each object is as much as possible encapsulated
> everything else.

Yes, but class attributes have very little to do with objects (except
the class objects themselves) and everything to do with the class. So
anything you need to know about the class rather than the object
should be stored in a class attribute.

Alan G.

More information about the Tutor mailing list