Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.lang.c++ Subject: Re: object-oriented design (was Re: are 'friend's really necessary ??) Message-ID: Date: 9 Apr 90 17:36:25 GMT References: <169@pollux.kulcs.uucp> <10589@alice.UUCP> <1082@targon.UUCP> <1110@targon.UUCP> <4593@pegasus.ATT.COM> <1115@targon.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 25 In-reply-to: ruud@targon.UUCP's message of 5 Apr 90 10:16:28 GMT 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. Even in these types of applications, there is more to be concerned with than just the structure of the data. There may also be rules that go with the data. For instance, updating an employee's record may invoke a rule against the company's financial records. This may not be hidden from the user (or it may), but the business rule must occur and, so, should be "tied" to the employees data structure. Sometimes (oftentimes), it is useful to hide this tie from the "ordinary" user who is not allowed to change the rule anyway. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"