Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!uc!shamash!tank!gargoyle!ddsw1!olsa99!oct1!proxima!lucio
From: lucio@proxima.UUCP (Lucio de Re)
Newsgroups: comp.lang.c++
Subject: Re: object-oriented design (was Re: are 'friend's really necessary ??)
Message-ID: <1282@proxima.UUCP>
Date: 9 Apr 90 23:08:08 GMT
References: <169@pollux.kulcs.uucp> <10589@alice.UUCP> <1082@targon.UUCP> <1110@targon.UUCP> <4593@pegasus.ATT.COM> <1115@targon.UUCP>
Reply-To: lucio@proxima.UUCP (Lucio de Re)
Organization: FLAGSHIP Wide Area Networks - Cape Town
Lines: 43

In article <1115@targon.UUCP> ruud@targon.UUCP (Ruud Harmsen) writes:
>Perhaps it all depends a lot on the kind of application.  In the ones
>I dealt with most (financial accounting, invoicing, banking etc.) the
>implementation of the data types, say the fields of the structs, are
>exactly what the *user* of the system deals with, viz. enters, browses,
>prints, talks about with his clients, etc.
>
>How could it be useful to *hide* these things, if to the *user* of the
>system, they are the only things that matter?  If you hide the data-items,
>nothing useful remains.

I think there is some confusion here. I presume (and I'm a bit of a
novice at this, so please be tolerant) that, whereas the *user*does*
want to see the fields separately, they are grouped at all times and
are very seldom manipulated out of context. Nobody contends that the
fields are not disjoint, but, in APL parlance, changing one element
of a matrix affects the matrix as a whole. Likewise, changing the
balance on a debtor record affects the entire record. Let's take one
example: Let's say that the internal representation of a debtor
consists of a master file record with debit and credit balances,
current and prior to the present, as well as the (active) history
in the form of transactions. It is arbitrary whether one wants the
occurrence of a new transaction to affect the debtor's balance in
the master file record or not, but it is not arbitrary that the
actual debtor's balance _is_ affected. Good design dictates that
the representation of the debtor in the computer system should be
such that the master file record is tightly coupled to the
transaction records, so that they are viewed by the system as a
single entity. That is how I perceive OOP to function, not as a
limiting factor that forces all objects to be lumped together, but
rather providing a unification glue so that aspects that belong
together are always kept that way.

Sorry to soapbox like this, I hope I haven't muddled the concepts
beyond understanding.

----------------------------------------------------------------------
I used to design nuclear reactors and you should see the code that
engineers and scientists come up with. Yuuuck! Spaghetti everywhere.
-------------------------------------------------- (Kenneth L Moore) -
Lucio de Re                        ...uunet!ddsw1!olsa99!proxima!lucio
-------------------------------------------------------- lucio@proxima
                Disclaimer: He must have been joking!