Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!hp4nl!targon!ruud
From: ruud@targon.UUCP (Ruud Harmsen)
Newsgroups: comp.lang.c++
Subject: Re: object-oriented design (was Re: are 'friend's really necessary ??)
Message-ID: <1110@targon.UUCP>
Date: 29 Mar 90 07:39:54 GMT
References: <169@pollux.kulcs.uucp> <10589@alice.UUCP> <1082@targon.UUCP> <626@ksr.UUCP> <4568@pegasus.ATT.COM>
Reply-To: ruud@targon.UUCP (Ruud Harmsen)
Organization: Nixdorf Computer BV., SWP, P.O. Box 29,Vianen, The Netherlands
Lines: 39

In article <4568@pegasus.ATT.COM> psrc@pegasus.ATT.COM (Paul S. R. Chisholm) writes:
>[...]
>In article <1082@targon.UUCP>, ruud@targon.UUCP (Ruud Harmsen) writes:
>> Only too true.  And isn't this also the fundamental weakness of the
>> object oriented concept?  For in the real world, and so in any
>> realistic information system describing a part of that real world,
>> *nearly all* classes are interrelated to *nearly all* other
>> classes.
>> [...]
>As Dr. Koenig pointed out in a later article, "interrelated" means "the
>implementation of one thing depends on the *implementation* of another
>thing".

If the knowledge of the "implementation" of a thing includes to know names
and types of the elements in a structure, it is my experience that some 70
to 80 percent of the code deals with several elements from several
structures, in many different combinations.  If then you try to restrict
direct access to the structure elements to functions of the same class,
while providing access from outside the class through functions, you may
have to create an individual function for every element.
This gives me the feeling that calling such a function becomes just a
syntactic variant of the "." and "->" operators, and only obscure things,
and help in no way whatever.

>A "thing" in this case may be a whole class.  If you're careful, only a
>few functions in class B (e.g., member function foo and static member
>function bar) will need to know about the implementation of class A; in
>which case, only B::foo and B::bar will need be friends of A.  This is
>a Good Thing; it specifically limits what software can mess with an A,
>and what code must be looked at when the implementation of A changes.
> [...]


In theory, this is correct.  But if in practice, in a particular
application 70 to 80 percent *has* to mess with a class A, then you can't
do very much limiting.
I think smart cross-reference tools, that tell you where the messing is
done, and also how (read-only, or write-also) it is done, are much more
useful, and can be applied to traditional languages just as well.