Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!sol.ctr.columbia.edu!srcsip!jhereg!ann!tce
From: tce@ann.MN.ORG (Thomas C. Evans)
Newsgroups: comp.object
Subject: Re: Comments on OOP style
Message-ID: <47@ann.MN.ORG>
Date: 12 Feb 90 15:50:23 GMT
References: <135300027@p.cs.uiuc.edu> <135300028@p.cs.uiuc.edu> <10527@microsoft.UUCP>
Reply-To: tce@ann.MN.ORG (Thomas C. Evans)
Organization: Kallestad Diagnostics, Chaska, Mn
Lines: 26

My approach to OOD has been touched on in various ways by this discussion.
One aspect of it I have termed "Middle Out" design, rather than top down
or bottom up.  The point is that that while the top level function may be 
described (don't we all like one line specs) the top level DESIGN is not.
I also start with the assumption that many small reusable parts are available
(reinventing wheels when your job is to build cars is counter productive)
so I don't start at the bottom.

The image I use is the Lunar Lander.  Its external shape could not have been
determined ahead of time, and was not designed.  Its external shape was
a product of lower levels of design requirements.  At the lowest level 
individual components reflected the contents of parts catalog and real-world
constraints, rather than Lunar Lander constraints.

My favorite design paper, in support of OOD & encapsulation is still:
  D. L. Parnas, "On the Criteria to Be Used in Decomposing Systems into
  Modules," CACM 5:12 December *1972*

 P.S. OOD was applied to COBOL, 
      its called Ada: the common defense oriented language
      also designed by a committee and forced as a standard :-)
  
-- 
Thomas C. Evans            self is like insanity,                tce@ann.MN.ORG
Minneapolis MN.           its hereditary and you        {umn-cs,amdahl,hpda}...
(612)448-4848 x285       get it from your children           ...!bungia!ann!tce