Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!newsfeed.internetmci.com!in2.uu.net!news.BSDI.COM!engr.orst.edu!reuter.cse.ogi.edu!qiclab.scn.rain.com!gemstone.com!servio!servio!aland
From: aland@servio.slc.com (Alan Darlington)
Subject: Re: Is good OOP becoming more Function-Data like?
Message-ID: <1996Apr18.171535.2009@slc.com>
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: servio
Organization: GemStone Systems, Inc., Beaverton OR, USA
References: <4knc10$4nh@newsbf02.news.aol.com> <4kpdl9$mt8@newsbf02.news.aol.com>
Date: Thu, 18 Apr 1996 17:15:35 GMT
Lines: 38

dogmat@aol.com (Dogmat) writes:
<snip>
> Or take a heat exchanger. There are several different types of heat
> exchangers: Shell-and-tube, double-pipe, plate-core, air-cooled, etc. A
> shell-and-tube heat exchanger is basically a cylindrical vessel with tubes
> in its guts. An air-cooled heat exchanger is a "box-shape" of a bank of
> tubes with a fan blowing air past them. In the hierarchial OOP model of
> the "hardware", these different types of heat exchangers turn out to be
> located in different places. However, they all share a common "process"
> model, namely two or more streams exchanging heat, which involves mass and
> energy balances, physical property models, etc.
> 
> So in designing the software, which hierarchy do we pick: the "hardware"
> model or the "process" model? They're totally different, and in fact,
> neither approach is acceptable. You cannot fit one model into the other.
> The resulting code is horrible. You're trying to combine two hierarchies
> which cannot be combined.

This is a pretty common problem.  At a former employer, working on a
portfolio management application, we found that the "logical" hierarchy
of securities (discount, coupon, government, etc.) was totally illogical
from a computational point of view.  Wildly differing kinds of securities
might use the exact same interest computation formula, for example.  So
we wound up inventing a whole new calculator hierarchy, which allowed us
to share computational code by having a calculator part as an instance
variable in the security hierarchy.

<snip> 
> In hindsight, the proper software design is absolutely clear. We need two
> completely separate hierarchies: One for the "hardware" model, another for
> the "Process" model. Then we associate the two.

Exactly...

<snip>

  Cheers,
  Alan
