From: harvey@opl.com (Harvey Reed)
Newsgroups: comp.object
Subject: Re: Maintenance and OO -- the problems of C++
Date: 28 Jan 93 22:21:12 GMT

fhd@panix.com (Frank Deutschmann) writes:
>In <harvey.728148390@regina> harvey@opl.com (Harvey Reed) writes:
>>pkeddie@axion.bt.co.uk (Paul Keddie) writes:

[NOTE:] please no smalltalk lover flames...

[NOTE:] IMO the choice of a language (particularly C++) has a lot
to do with economic forces, not technical forces. The original post
(from Paul) was talking about OO, but did mention C++, so the thread
gets involved with that line of thought. If we keep discussing
C++ program maintainance specifically (and I'm happy to do so!) we may want to 
move this to comp.lang.c++ where there are similar dicussions about
maintainance (and the corresponding embers and flames...)


>>>1) Are 00 programs harder to maintain than normal functional programs?
>						    ^^^^^^^^^^
>I assume that PKeddie really meant traditional structured programs.

>>[...]
>>Maintaining OO (and C++) requires a more global understanding
>>of the system than with C.
>>[...]
>>so the end result
>>is that fixing a line of code can have impact throughout the system.
>>[...]
>>IMO debugging an OO system is more tedious than traditional C.

>Isn't this exactly the OPPOSITE of what the goals of OO are?
>[...]
>The major flaw of C++ which causes the rippling change effect is that
>C++'s requirement for strong type checking leads to heavy base
>classes, while the Smalltalk/CLOS approach leads to lightweight super
>[...]

I guess that's the difference between static type checking
(C++), and more of a run-time environment (SmallTalk). I
don't know if I would call it a flaw, it's just the approach
that was taken.

>(As an aside, it would seem to me that this problem would prevent any
>sort of mathematical model of OO from covering both Smalltalk/CLOS and
>C++ environments.  In other words, while we may talk about all of
[...]

I'm no expert here, but I'm sure there is a common subset that could
apply to both.

>This problem is the dirrect cause of maintainence headaches: to add
>behavior, the maintainer needs to chase inheritance towards the
[...]

Well... I think of it as a challenge...

[...]
>is the pointer to member: with the introduction of this special type,
>C++ has created a pointer which is address arithmetic incompatabile
>with other pointers.  This is not a good situation!
[...]

I believe the stated position of those who would defend C++
is that a pointer to a member is definately NOT a pointer,
so the above doesn't apply. But, that's not to say that such
notions add to the clarity of C++ terminology.

-----------------------------------

>IMO, these problems lead not only to maintainence problems, but also
>prevent the original goals of OO: simplified systems maintainence to
>keep up with evolving systems needs, and reuse of completed
>development effort.

Again, I am sympathetic to your concerns. However I have built
many large C++ systems, and find the process pretty easy to deal
with... provided you and your team-mates have DISCIPLINE!
Not to knock SmallTalk lovers, but many of the arguements
for SmallTalk revolve around the more dynamic nature of the
language.

IMHO, if a domain problem has been thoroughly analyzed, and the
design is attended to by experienced developers, then you CAN end
up with a system that is easier to deal with than the equivalent
average quality C system.

This requires that the churning of requirements and design
decisions are kept to a minimum. I am NOT promoting waterfall
process, I believe in (for quite a while now) the spiral
process. However, the spiral has to be conducted in such
a way as to spew out the chunks of design in such an order
that they won't change a whole lot later. This is the hardest
part for developers to get. This is where human experience
comes into play.

Regardless of language, I would use the approach above by the way.
Now, for C++ what you are left with is a system that is a bit
more "brittle" than a smalltalk system, but is that so bad?
A properly documented system is maintainable.

I think that on the other side of the coin, folks used to
smalltalk tend to make quicky-little-prototypes, and hope
they scale. Folks used to C++ know that this is impossible
to cope with in C++, so there is less of a tendency for this.

I don't think the "extremely-flexible-make-a-small-prototype-
into-a-real-system" is one of the true promises of OO. And I don't
think that large C++ systems violate promises of OO, but I DO THINK
that it takes a lot more discipline in C++!!




-- 
++harvey
===========================================================================
internet:       harvey@opl.com  /  hreed@cs.ulowell.edu  /  h.reed@ieee.org
voice/fax:      617-965-0220    /  617-965-7599
Newsgroups: comp.object