[Tutor] Follow up to 'class data'

alan.gauld@bt.com alan.gauld@bt.com
Thu, 6 Dec 2001 11:37:37 -0000

> > In OO terms classes define templates from which we create objects
> > - a better term is instances, it it disambiguates from pythons
> > more general idea of objects.

> Let's say I write a compiled Basic program called AddressBook.exe that
> produces a pipe-delimited flat file with names and addresses in it.
> Anybody that runs it gets exactly the same address book 
> output; but with
> their own data.  One could run several "instances" of it on the same
> computer - ie, "business addresses", "personal addresses", "club
> addresses", etc.  Where does this differ from a class?

At that level not at all. The program is acting as a cookie cutter
for different instances of address book.

> > class Entry

> > Now we can have an address book that contains different
> > types of entry by subclassing Entry:
> >
> > class Building(Entry)
> >
> > class Person(Entry)
> You just lost me.  What would be the point?

Because you would likely do the same operations on all sorts 
of Entries but do them slightly differently depending on the 
Entry type. A building has a single name but a person has 
first and last for example...
Sorting would likely be by address say for a building but 
by last name for a person so the compare method of each would 
be different.

> I restrict it, AddressBook.name could just as easily be "Empire State
> Building" or "pothole at fifth and main" as it could be John Doe.

Could be, but thats a data oriented view. When you come to 
use those entries you would find the soirting, searching etc 
very limited in effectiveness if you treat them all the same.

> > > class AddressBook:
> > >    class Input(AddressBook):
> >
> > Categorically NO. Classes are not functions!
> What is the difference between class Input(AddressBook) and class
> Entry(AddressBook)?  To me "data input" == "data entry"

Maybe I misunderstood the intent. I thought the Input class
was intended to capture all the different ways to read input.
The Entry class by comparison holds an actual addressbook item
- including how it reads its own input etc.

> I don't think I understand this either.  Do you mean I 
> shouldn't provide attributes for length, width, thickness, 
> color of cover, etc? 

No, provide the attributes by all means, but don't necessarily 
provide methods to:

getLength/setLength, getWidth/setWidth.
(This is rarely seen in Python because attributes are 'public' 
by default. But in languages like C_++/Java it is common for 
beginners to proivide a bunch of attributes and then a bunch 
of get/set methods to access them - this completely destroys 
the OOP way of working!)

> one would need to make Name, Address, Phone, etc. "exposed."

Absolutely. So for these get/set would be OK.
But let's imagine Address is represented by several 
fields: HouseNo, Street, Town etc

We only need to print Address not the separate Fields
(at Address Book level) so we only need a getAddress method 
not individual ones for each field. That method would output 
all the fields in one go. Of course a better solution is to 
make Adddress an object in its own right.... but even then 
we may not need get/set for each field.

> > Classes are 'living breathing things' that  know stuff and
> This smacks of anthropomorphism.  

Absolutely correct and that's how you can approach OOP.
The objects are 'alive', they communicate with each other 
via messages. 

> > As Peter Coad says: "Objects do it to themselves"
> I found, much to my amazement, OOA and OOP by Peter Coad in my local
> library.  OOA will be returned with all but the first 50 pages or so
> unread.  

Please read the rest too. Coad's OOA is a great intro to OO and one 
of the books that really made the light come on for me when I first 
read it - 10 years ago, eek!

> Completely incomprehensible to me.  I'm struggling with OOP; 

The OOP book is very good but requires that you understand 
the OOA stuff first to be honest. Timothy Budd does the same 
kind of thing as Coad's OOP book but IMHO does it better...

Stick with it, it does make sense eventually.

Alan g.