NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/cplus/16722

Text File | 1992-11-21 | 4.2 KB | 120 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!psinntp!uu0465!andrew
From: [e-mail] (Andrew Gideon)
Subject: Re: Complexity in the eyes of the beholder?
Message-ID: <[e-mail]>
Sender: [e-mail] (Andrew Gideon)
Organization: TAG Systems inc.
References: <[e-mail]> <[e-mail]>
Date: Fri, 20 Nov 1992 21:53:32 GMT
Lines: 108


In article <[e-mail]> [e-mail] (Karl Nicholas) writes:
>In article <[e-mail]> [e-mail] (Andrew Gideon) writes:
>>
>> ...
>>
>>To me, I achieve my goal (except when I violate my own
>>rules - which does happen more frequently than I like {8^).
>>But this coworker claims that the many levels are too
>>complex to follow.  In trying to understand a class, he
>>is forced to recurse too frequently and too far.
>>
> But why is he recursing into the subclasses? It would seem
>to me that he should be taking the classes that he deals
>with for what they are, and not worry about how they work.
>

There are two reasons for which one might recurse "downward":

1.    Lack of understanding of the class being used
    (ie "what does this method do?")

2.    Looking for a bug

The frequency of reason 1 can be reduced with good documentation.
I doubt that it can be eliminated completely.  I am full of praise
for the Rogue Wave documentation, for example.  But occasionally,
I get a better understanding of behavior - and we are talking
merely about *interface* behavior here - by looking through
the code.

The frequency of reason 2 can be reduced by writing code with
no bugs {8^)

BTW, the term "recursing" may be unfortunate, in that it does
gloss over a significant cause of difficulty here: virtual
functions.  Often the "recursion" is actually away from an
inheritance graph root.  Further, the actual method being invoked
may not be discernible through static examination of the code.
Multiple Inheritance also adds to the complexity of the
"recursion" process.

I know that I am arguing his side here.  As I said, I do
see his point.


More on reason 1:

void foo(SomeArbitraryClass *obj)
{
    obj.doSomething();
}

What does foo() accomplish?  If I (the class designer of
SomeArbitraryClass) do my job well, the action of foo() should be
expressible as a single function, regardless of the actual
implementation of doSomething() which is selected.

But...can I (still the class designer) guarantee this?  Perhaps
someone else has a subclass of SomeArbitraryClass which defines
a doSomething() such that the documented function of foo() would
not be correct for objects of that new class.

Perhaps the words that I choose to describe the function of
foo() have a different meaning to the reader of the documentation.

I just do not know the answer to this.  Is it merely (merely?!?!)
a question of "clear design" (ie principle of least astonishment)
and documentation?


>  I think the tradeoff is speed of code verses modularity.
>many classes supports modularity, which from a systems
>standpoint is preferable, where larger classes supports
>speed of execution, which from a user standpoint is
>preferable. I try to incorporate as much modularity
>as possible until the speed for the user becomes a problem.
>

Ha!  I'm not even thinking about considering the act of
going near the cabinet in which resides this can of worms.

Besides, with good compilers and careful inlining... {8^)



Thanks...

    Andrew Gideon

P.S.    I needed a word in the above discussion that I
    could not recall.  I used "inheritance graph
    root".  What I wanted was a node in a directed
    graph (acyclic) which has edges leading only outward.
    This node represents a class which is a base class
    of n (n>=0) other classes, and which has exactly 0
    base classes of its own.  What is a word for
    this?

===
 -----------------------------------------------------------
| Andrew Gideon              |                              |
| Consultant                 |                              |
|                            |   TAG Systems inc.           |
| Tel: [phone]        |   D2-181 Long Hill Road      |
| Fax: [phone]        |   Little Falls, N.J., 07424  |
| [e-mail]          |                              |
 -----------------------------------------------------------