The idea of "objects" is a familiar one to any Delphi programmer, and to a
lesser extent, Paradox programmers.  The Delphi VCL (Visual Component
Library) is an enormous tool-kit of Delphi objects, from "TButtons" to the
mundane "TList," upon which all Delphi applications are constructed.  Even
the smallest Delphi application routinely has up to a megabyte or more of
this supporting code under it.
This is what I call "ba{*word*224}t code," or "foundation code."  

Trouble is, it's easy to build an application -- using these ba{*word*224}t
objects -- which does not have /any/ real "object oriented" structure unto
itself.

In my view, a well-designed application exhibits three distinct layers of
object-based structure.  Code is found (1) "in the ba{*word*224}t," as described
earlier; (2) "in the back room;" and (3) "in the showroom."

The "showroom" is whatever object-oriented metaphor you present to the
end-user and you expect him to use.  For example, if users work with your
program by dragging icons around ... or double-click on a record to edit it
and then file it away again ... that "thing" is a showroom object.  [Nope,
I promise not to write a book on these terms, nor to charge you $3,000 to
sit in on a seminar where I read said book to you.]  It's something that
/in/ /the/ /user's/ /mind/ is a "thing" that he or she works with in the
real world and that has an analog somehow in your program.  Many programs
have such a metaphor in their user-interface even if they're not object
oriented programs.

The "back room" is the world that you, the /programmer,/ live and work in.  
The objects you build and use here are _application_ specific and exist for
your convenience.  They are chosen and built to reduce the amount of code
that you must write, and (perhaps most importantly...) to reduce the number
of points that you must consider and/or change when modifying the
application.

It is very easy to drop into the habit of writing code that is /very/
dependent upon your database schema.  This causes code to be scattered
throughout the application that is dependent upon the present structure of
the database...  /all/ of which could subsequently break when the structure
is (inevitably) changed.  It also causes /logic/ and /tests/ to be
scattered, e.g. "If MaritalStatus = 'M'" instead of "If
Customer.IsMarried")

Remember this:  programs as they are originally written, by the original
programmer who wrote it, usually work pretty well (or not at all).  The
trouble starts when you have to _change_ something.  The trouble occurs
when you /overlook/ something or when an uncontrollable /ripple/ starts.

/Design/ your programs to facilitate change.  These factors need to be taken
into account at the earliest possible point in the program's writing.

Also, (and I say this somewhat hesitantly...) don't be afraid to _s{*word*99}_ old
code and "rewrite it properly" if you can convince yourself /and/ one or
two of your peers(!) that by doing so you can make its problems "really go
away for good."  

----------------------------------
Fast automatic Paradox/Delphi table repair at a click of a mouse!
http://www.sundialservices.com/products/chimneysweep

Don't tell your professors, but ... I'm not really sure that I "buy" that
line of reasoning; nor that I really ever have in 25 years or so of doing
this crazy stuff.  Modeling the world as "entities" and "relationships"
sounds fine but the real world is awfully hard to model that way.  The
whole thing really becomes complicated ("begins to break down") when you
have to interact with an existing database ... or when you must change the
application to suit a new requirement.  So I tend to think of ER modeling
as being useful mostly as a conceptualizing tool.  My experience does not
tell me that a real-world application can be built that way.

Remember also that there's often a huge gap between the "data model" (or the
application architecture!) that you must program against, and the
"conceptual model" that you want the user to carry in his or her mind while
using your system.  Consider for example the relatively simple model
presented by an ATM machine, or a bank in general.  As seen by the
end-user, most of the bank's "world" is quite invisible and deliberately
so.  An ATM-machine is strictly a "purpose-built machine," and so are most
computer programs.

The ER-model expresses "things" and how "things" relate to one another, more
or less, but it says nothing about how they /move/ and /interact./  It says
nothing about rules which define which interactions are possible (deduct
money, followed by cash dispense) and which are not (account is overdrawn,
dispense cash anyway, oops).  So for all the "good" things inherent in the
ER-model, there are a lot of limitations too.  And the textbooks that I've
read for review usually don't go into that.  Which is why, in my classes, I
usually don't use those (or any) textbooks.

My students like that.  My bookstore doesn't.

Well, VB is a fairly decent tool as far as it goes, but I honestly wish that
BillG wasn't quite so enamored of it.  His business has kinda got "a decent
low-level tool" (now that C# is here anyway), and "a decent macro tool" in
VB, but nothing in the middle and all of it /extremely/ dependent on
VBXes... oops, OCXes.  Which creates a huge versioning problem, but I guess
I've wandered fairly off-topic now.

You can write good software in anything.  You can write bad software in
anything.  And the more software you write, and the more software you
encounter, the easier it will be to see what I mean.

True.  One of my classic lessons for a Sofwtare Architecture class was to
hand out floppy-disks with [sanitized, anonymous] other people's programs
on them.  With each disk I handed a list of requirements:  changes to be
made, "the programmer got hit by a bread-truck and he left it
half-finished," or simply, "we lost the comments [of course I'd stripped
them out], figure this thing out and put 'em back in," or even, "the name
mangler chopped up the variable-names in this program...  choose
appropriate names and fix them," stuff like that.  /Real/ /world/ /stuff/
like that.  Gave it to 'em on Thursday and it was due the _next_ Tuesday.  
{Billy Joel:  /pres-sure/ !!}  

It was an awfully quiet Tuesday.  But that was _real._

----------------------------------
Fast automatic Paradox/Delphi table repair at a click of a mouse!
http://www.sundialservices.com/products/chimneysweep

And that is unfortunately where the concept fails.  Even in the simple world
of desktop databases, there's almost always an "existing database" and
maybe half a dozen of them with different formats.  (When for example a
cell phone company buys another cell phone companies, their incompatible
billing systems and equipment must now somehow be integrated.)

"Starting over" is simply not an option when a single programmer costs
nearly $100,000 a year in salaries-and-benefits alone.

Okay, now for the real world:  "you can't do that."  The billing systems run
against that database continuously every hour of every day.  The company
cannot afford the _risk_ of disruption of service.  It is therefore an
immutable constraint, /not/ subject to discussion, that "you can't do
that."

It's a good tool for conceptual understanding.  But the Holy Grail of
automatic production of practical software from it is just as far away as
ever.  (But a handful of strange-looking Englishmen seem to be in quest of
it .. they appear to be riding broomsticks.)  ;-)

Nope, it's not an object and not a factory.  It's a purpose-built machine.

And still not acknowledged.  Microsoft sees nothing wrong with VB and uses
it in dozens of incarnations ... ASP, VBforApps ...

Be kind to your teacher.  Teaching programming classes is tough.  :-)

ER is an excellent way to present the concepts, especially to students, and
it's a good framework that can be referenced by a group of programmers and
designers to help them work together.  You /need/ such a "common frame of
reference" in a big design project.  But, as with all tools, you must also
know where the boundaries of the tool lie.  A screwdriver is useless for
driving a nail.  A hammer is useless for driving a screw.  Both tools are
for the purpose of "binding things together."  And perhaps the most
important tool of all, in /any/ construction project, is a piece of paper.

You have students? I don't think you mentioned that before.

Groetjes,
Maarten Wiltink