[Tutor] Follow up to 'class data'

[fleet@teachout.org]

Sorry for delay in replying - out of town.

On Tue, 4 Dec 2001 alan.gauld@bt.com wrote:

> 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.
>
> > So to me, the address book is an object and can be a class?
>
> So you could create an AddressBook class which would be a
> template from which you could create multiple instances,
> each of which would be an address book. Each address book
> would have the attributes you define in your AddressBook
> class(the methods and fields) but have their own values
> stored in those fields.  Thus your father's address book may
> hold different names to yours.

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?

> > I would have thought "address book" would be the class and
> > the means of adding, modifying, deleting data would be "methods."
>
> Could be, and the data itself could be defined as classes
> - Entries for example. Thus:
>
> > The structure as I see it would be something like:
> >
> > class AddressBook:
> >    def input:
> >    def modify:
> >    def delete:
> >    def search:
> >    def sort:
> >    def output:
>
> Is fine, and the entries could look like:
>
> class Entry
>     def input
>     def edit
>     def compare(Entry)
>
> Now we can have an address book that contains different
> types of entry by subclassing Entry:
>
> class Building(Entry)
>     def input
>     etc...
>
> class Person(Entry)
>     def input
>     etc...

You just lost me.  What would be the point?

"Input" would need to handle "name," "address," "email," etc.; but unless
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.

> The AddressBoook class writes its methods to use the Entry
> methods(eg compare(Entry) would be used both in searching
> and sorting...) But we can have both types of Entry
> (Building or Person) stored and AddressBook doesn't care,
> it just sees Entries!
>
> > class AddressBook:
> >    class Input(AddressBook):
> >       def inputName:
> >       def inputAddress:
> >       def inputPhone:
>
> Categorically NO. Classes are not functions!

What is the difference between class Input(AddressBook) and class
Entry(AddressBook)?  To me "data input" == "data entry"

> Occasionally, very occasionally, we write classes that look
> like functions but its not normal practice. Similarly its
> not usually a good idea to provide set/get methods for
> every internal attribute - a common beginners mistake.
> Only expose those attributes that the outside world needs
> to see.

I don't think I understand this either.  Do you mean I shouldn't provide
attributes for length, width, thickness, color of cover, etc?  Certainly
one would need to make Name, Address, Phone, etc. "exposed."

> Classes are 'living breathing things' that  know stuff and
> how to deal with that stuff. When thinking about classes
> ask "What does Foo know? And what can Foo do with what it knows?"

This smacks of anthropomorphism.  (And this statement may have a great
deal to do with my lack of "getting it.")

> 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.  Completely incomprehensible to me.  I'm struggling with OOP; but
I haven't quit yet.

				- fleet -