[Tutor] Follow up to 'class data'
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
> 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:
(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
> > 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
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.