This is a good example of lack of reusability (or better, poor
encapsulation) at the design, rather than the implementation, level.
I completely agree that when our design proves a poor match for an
unanticipated usage scenario, we are helpless to address it (aside
from ugly kludges or extensive rework). Design patterns represent one
attempt to deal with this problem, but it is embarrassingly difficult
to even come up with a simple definition of pattern. In fact, in
their seminal work Gamma et al. (the "Gang of Four") basically
presented a catalog of patterns (after some preliminary discussion)
and in effect said: They're things like these.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The policy of being too cautious is
the greatest risk of all."
--Jawaharlal Nehru
On Jul 12, 2005, at 7:32 PM, Richard G. DAVIS wrote:
The example I usually choose to illustrate the issue is the VistA
PATIENT
file. Consider the LABORATORY system, and what happens when the
Infectious
Disease personnel bring water samples to microbiology taken from
the ice
machines in the food service areas. When asked for the patient to
be used
for the transaction, what does VistA do with ice machine data.
Or, consider the Research Service personnel who bring blood samples
from
dogs and cats. Again, VistA is helpless to deal with these
instances of
samples that lie OUTSIDE the domain of what is implemented in the
semantics
of the PATIENT file #2.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
