Board index » delphi » TechTips: Back-room and showroom objects

TechTips: Back-room and showroom objects

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

 

Re:TechTips: Back-room and showroom objects


Quote
Quivis wrote:
> -> is (inevitably) changed.  It also causes /logic/ and /tests/ to be
> -> scattered, e.g. "If MaritalStatus = 'M'" instead of "If
> -> Customer.IsMarried")
> So, I guess, you can say that building a computer program in theory
> is no different than creating a conceptual diagram using ER modeling,
> taking into consideration all the entities (objects) you have to
> create, the attributes (properties) of these entities and so on,
> which eventually (hopefully) leads up to the completed database
> (application)...?

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.

Quote
> -> Remember this:  programs as they are originally written, by the
> original -> programmer who wrote it, usually work pretty well (or not at
> all).

> Tell me about it... ;)  I currently (being forced to) take a course
> in VB-6. E-eww! ;-)

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.

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

> I don't think that will be an issue: convincing yourself is quite
> easy, but what comes out of the re-make has got to be better than
> what you put it...that's the tricky part! ;-)

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

Re:TechTips: Back-room and showroom objects


Quote
Quivis wrote:
> The ER modeling should, so I think, only be used when you create a
> new database. Not when trying to add to or alter in other ways an
> already made one. Then I think it would be far easier to start over,
> depending, of course, on the complexity of the database.

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.

Quote
> I've seen examples of this (no more than two weeks ago) where some
> dude has stuffed everything (loads of field names) into just a couple
> of tables. Now, that's crowded. For this example it would be easier
> to start over and design the database from scratch. It is virtually
> impossible to change things in it without breaking it. It breaks all
> the rules in the book, as far as I can tell, so my fingers itch.

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

Quote
> Well, as I said: "in theory." My theory was that the ER modeling
> could be a way to think about objects, not really how to develop real
> programs in real life. More like a hook on which to hang things, if
> you catch my drift. Then one could in fact use ER modeling as a tool
> for understanding objects and their relationships inside a program in
> a visual manner. Perhaps it would be easier for some to understand
> the concept this way.

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.)  ;-)

Quote
> Hmmm, yes, from the programmer's perspective, the ATM machine would
> be an object, right? Or perhaps a factory, which generates objects
> you could do work with. It's just that, when the object is destroyed
> and you have to get a new one from the factory, it may be out of
> objects. Perhaps not such a good analogy after all...

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

Quote
> Yes, the OCX/VBX problem. All too familiar.

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

Quote
> That's a very good idea. In my VB class the teacher has given us an
> assignment to write two programs from scratch: one that draws all the
> towns in Sweden (I'm Swedish) onto a picture component, and uses ADO
> to connect to an Access database for retrieving the data to put on
> the "map" such as town coordinates, towns' names and the population
> in the towns; the other interacts with ArcMap (GIS software) using
> COM and it should use the same data as the first program.

> Now, luckily for me, I know a bit about programming since before, but
> many in the class are novices and have trouble understanding what
> they should do, and where to do it. Personally I think she started at
> too high a level for a beginner's class. But since the course is only
> eight weeks, and all we get, she also has to apply what you said:
> pressure.

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.

Re:TechTips: Back-room and showroom objects


Quote
Sundial Services wrote in message ...
>My students ...

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

Groetjes,
Maarten Wiltink

Other Threads