Re: C++ not OOP? (Was: Language Efficiency

[rmartin@rcmcon.com (Robert Martin)]

>pete@borland.com (Pete Becker) wrote:

>> 	Suppose you are evaluating a new language, say, C+#, and you 
>> hear from a reliable source that it is a "pure OOPL". What conclusions 
>> can you draw about this language that would tell you whether it is 
>> better suited to your purposes than, say, C+$, which is not a "pure 
>> OOPL"?

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>The conclusions that I would draw are:

>   #1. All code must be attached to objects.

>      i. I will not be able to write a procedure that
>         is independent -- it must be attached to an object

This does not guarantee that the stucture of your procedures or your
objects will be in any way superior to those written in C+$.  So of
what use it it?

>     ii. It would behoove me to have an Object-Oriented
>         Design (as opposed to a Structured Design) of
>         the system before I start coding in C+#, because
>         writing structured code will not be an option.
>         (Yes, I can kludge it by having just one object,
>         and attaching all of the code to that object, but
>         the result technically would still not be an
>         example of "structured programming," but would
>         rather be an example of BAD OO programming). 

Saying that it is BAD doesn't eliminate it as an option.  In any case,
you could make the identical argument about C+$.  It would behoove you
to have an object oriented design!

>    iii. My programming team had better be fluent in OO
>         concepts before using C+#, because there is no
>         mechanism for writing structured C+# today, and
>         gradually growing into Object-Oriented C+#
>         tomorrow.

This is the same argument as number ii, just rephrased.  In any case
it is just as true for C+$.  Your programming team had better be
fluent in OO if they are going to implement an OOD.

>     iv. Since it is a pure OOPL, there is a great
>         likelihood that the language itself is of
>         a fairly simple and elegant design. OTOH,
>         C+$ will probably be a very complex language,
>         since it supports two different programming
>         paradigms (structured and OO). 

I am sure that you cannot substantiate this claim.

>         Also, with
>         C+#, I can rest assured that the syntax is
>         uniform (all procedures will have an object
>         ID prefix). 

What do you mean?  A prefix?  Do you mean that all procedures will
belong to an object?  Isn't this your point i above?

>         C+$ would allow me to have SOME
>         procedures WITH an object ID prefix, and some
>         WITHOUT one. This could lead to confusion for
>         the maintenance programmers. 

How?  

>         Also, such code
>         would represent a rather messy, inelegant
>         design, which would be less of an option in C+#.

Why?  Are designs with nothing but objects always cleaner than designs
that sometimes have global functions?  I'd like to see the proof of that.

>   #2. All data must be encapsulated within objects.

>      i. There will not be any variables that are global
>         to the application, unless they reside in a
>         "root" object. Even in this case, we can have
>         more control over their scope and accessability
>         than would be avalable in C+$. In C+$, any global
>         variable we have would be accessable by ANY
>         procedure we write. In C+#, this would not be
>         the case.

Unless all procedures and data were in the same object.  Then there is
no control at all.

>     ii. I can create new data types more easiliy, by
>         deriving them from existing data types, then
>         changing only that which needs to be changed,
>         and inhereting the rest of the functionality
>         from the parent data type. Since C+$ is not
>         a pure OOPL, then variables are not objects,
>         and therefore I would not have this capability.

In C+$ you would have this ability with any kind of variable you
desired to have it with.


-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++