[Tutor] Follow up to 'class data'

dman dsh8290@rit.edu
Thu, 6 Dec 2001 17:38:59 -0500

On Wed, Dec 05, 2001 at 09:48:18PM -0500, fleet@teachout.org wrote:
| 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 say that the difference is "AddressBook.exe" is an entire
program (in binary format).  A class is simply a structural entity to
ease programming, and a single program can (often is if the langauge
supports it) composed of more than one class.

Regardless of whether or not you used classes the program would need
to know how to read from a file and understand that the interesting
data is separated by "|" and newlines, and what the interesting data
is supposed to mean.

Each program must also explicitly write the in-memory data to a file.
Classes don't automagically do that.  

If you think about it, everything in the computer is nothing more than
a series of bits.  Whether the program is written in Python, C++,
Java, COBOL, or BASIC it all ends up mapping onto the same set of
machine instructions.  The only difference is the way you, the
programmer, express those instructions to the computer.  At runtime,
classes don't exist (well, since python is interpreted you could say
they do, but in C++ or Objective C they don't).  At runtime all there
is is a bunch of bits.

| > 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."

Suppose, for example, you wanted to store your address book in a SQL
database instead of a file.  You might have a "primary key" that
consists of a number unique to each entry.  This id should not have
get/set methods because it is an implementation detail of the entry
and it should not be used or modified by clients.  This is where
encapsulation becomes relevant.  You can switch around the persistant
data store (files like you describe above or a SQL database) and
clients don't know nor care about it, it just works.

I hope this make things clearer for you.



If your life is a hard drive,
Christ can be your backup.