On (03 May 97) Benjamin L Mcgee wrote to Craig A Mckay...
 BL>  Now, according to your advice above ("start with a spec, and isolate
 BL> the components") to get my program off the ground I should do this...
 BL>  System Specifications: 
 BL>      1. Take input from C module files. 
 BL>      2. Output to individual files all procedures found on 
 BL>         input. 
 BL>  Now that I have my system's specs I should NOT do this... 
 BL>      1.  Create input function 
 BL>      2.  Create search function 
 BL>      3.  Create output function 
 BL>  But I SHOULD do this... 
 BL>      1.  Create InputFile object of 
 BL>           // the InputFile object knows that it is a C module 
 BL>      2.  Create OutputFile object 
 BL>           // the OutputFile object knows that it is a C procedure
Maybe, but maybe not.  There are quite a few ways to deal with any given
problem.  In this case, the input and output are almost incidental to
the real problems - reading input is pretty trivial, and writing the
output is even simpler.  The real problem here is finding the functions
in the text you read - trust me when I say that this is quite a complex
problem to deal with correctly.  Objects here are likely to include a
lexer, a parser and a symbol table.  These will doubtless use various
auxilary classes as well, but they're likely to be the main ones.
 BL>  What I think I have learned so far...
 BL>      1.  A program can be written in C++ without using object oriented
 BL>          design.
This is definitely true.
 BL>      2.  A program can be written using object oriented design without
 BL>          using an object oriented language.
This is also true, though as you might expect, implementing your OO
design without an OO language is often somewhat clumsy.
 BL>      3.  Numbered lists really look cool.
I prefer bulletted lists myself, but they're harder to handle in ASCII.

 BL>      4.  Object oriented design is concerned with the actual physical 
 BL>          objects that a program interacts with.  I.E. disk files, the 
 BL>          screen, the keyboard, etc... 
Not necessarily.  Certainly when you deal with physical objects, they're
often modelled well by objects in your programs.  However, many objects
in programs are for things like data structures that have no physical
analogs at all.  Others are used for things be modelled in the program,
that have physical analogs, but ones that don't directly interact with
the program itself.
For the sake of clarity, many demo programs make a conscious attempt at
creating objects for which there are direct physical analogs. This is
(usually) more to help clarify ideas than because it's the only
possibility.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------