Where's the OO? (was: Re: Learning Curve for C++ and Smalltalk)
Stephen G. Edwards
Let me try to nudge this juggernaut of a thread in a slightly different
direction:
In article <1993Apr29.1...@ucc.su.OZ.AU> John Max Skaller,
max...@physics.su.OZ.AU writes:
>In article <1rjrmo$1...@kong.gsfc.nasa.gov> Stephen G. Edwards
><edw...@kong.gsfc.nasa.gov> writes:
>>In article <1993Apr27.1...@ucc.su.OZ.AU> John Max Skaller,
>>max...@physics.su.OZ.AU writes:
>>>> If you have no familiarity with object-oriented programming, it's
>>>>worth learning Smalltalk to see what it's all about. C++ will make more
>>>>sense after you've seen Smalltalk.
>>>
>>> I really worry about that statement. I dont see that C++
>>>and Stalk OOP are that similar. The techniques that make sense
>>>in Stalk are often extremely bad ideas in C++: IMHO.
[Some surprisingly convincing stuff I babbled about Smalltalk helping you
learn OO and hence C++]
> I think you have presented an excellent case which reinforces
>the caution of the statement I made "I really worry about ...":
>
> From your description, I worried too much :-)
Thanks. Now let me tell you what worries me. There seems to be a growing
antipathy in this group towards the use of the object-oriented features of C++
in favor of more ADT-based approaches. For instance, class hierarchies seem
to be frowned upon. Downcasting has been blasted endlessly. Many posts site
the overuse of virtual functions as an evil. A wide berth is given to
multiple inheritance and virtual bases. Am I right, or is it all in my head?
This is fine, there are some ways to use the language that are better than
others. I avoid dangerous features where possible, too. The problem is that
I don't see much to balance the negativity. In particular, where are the
success stories that rave about the use of polymorphism (via inheritance and
virtual functions) as a vital element in the success of the design? In
conjunction with encapsulation, I think this is where the true power of OO
lies.
I recently completed a 2.5 year OO-designed C++ project. Despite my best
efforts, there just wasn't much polymorphism in the system. Very few classes
seemed to make much use of virtual functions. The class hierarchies were very
shallow, and most seemed to exist just for implementation, not to represent
is-a relationships. The ones that did showed pretty trivial gains in
functionality/code reduction.
Now we did deliver on time and showed some pretty amazing productivity. We
used the heck out of the ADT features of C++. But, golly, if all I wanted was
abstract data types, I could just use Ada (please note the tone of
exaggeration in my voice). I'm also pessimistic about how well the system can
be reused and extended, as it was meant to be.
I'm really gloomy now because I'm helping out with another project that's
starting to shape up the same way.
> Perhaps in "unlearning" some of the Smalltalk things, you
>became much more aware *why* certain things work well in Stalk and not C++,
>and vice versa?
There's probably nothing you don't alreay know. Smalltalk has a single rooted
hierarchy; C++ doesn't. Smalltalk is typeless; C++ is strongly typed.
Smalltalk has GC; C++ has memory management. I admit it still mystifies me a
great deal.
But I long for that "plug and play" feel you get from Smalltalk. I want to
write LOTS of C++ code that says, "just gimme a T*; I don't care what it
really points to, I'll just use it to do my job!" instead of just little bits.
What's my problem (be kind now...)? Is it because I'm not using a nifty COTS
class library? Because I still haven't read Coplien or Cargill? Or have I
just not got the hang of it yet?
Is there anybody out there who is doing real world C++ applications with a
truly OO flavor? How do you do it? But please, no more GUI stories, thank
you. We all know that a TextEditor isa ScrolledWindow isa Window isa blah
blah blah.
> Oh, that is so well said. Thank you.
Stop that. You're just encouraging me. :)
---
Stephen G. Edwards Phone: (301) 286-6676
NASA/Goddard Space Flight Center Internet: edw...@kong.gsfc.nasa.gov
Code 522.2
John Max Skaller
>
>Let me try to nudge this juggernaut of a thread in a slightly different
>direction:
>
>In article <1993Apr29.1...@ucc.su.OZ.AU> John Max Skaller,
>max...@physics.su.OZ.AU writes:
>>In article <1rjrmo$1...@kong.gsfc.nasa.gov> Stephen G. Edwards
>><edw...@kong.gsfc.nasa.gov> writes:
>[Some surprisingly convincing stuff I babbled about Smalltalk helping you
>learn OO and hence C++]
>
>> I think you have presented an excellent case which reinforces
>>the caution of the statement I made "I really worry about ...":
>>
>> From your description, I worried too much :-)
>
>
>Thanks. Now let me tell you what worries me. There seems to be a growing
>antipathy in this group towards the use of the object-oriented features of C++
>in favor of more ADT-based approaches.
ADTs are prefered, I think, because they are properly supported.
That is, provided you define copy, assignment, etc etc, ADT classes
just work. No complicated memory management strategies are involved:
C++ is the ideal language for ADTs (values).
>For instance, class hierarchies seem to be frowned upon.
Yes. I frown on the word 'heirarchy' meaning Object Heirarchy:
a tree structure with 'Object' at the root and from which are derived
classes of increasing functionality.
>Downcasting has been blasted endlessly.
Because its use is unsafe in the sense it defeats static
checking: one of the main advantages of C++. It may also
break the open/closed principle, and generally causes clients
to become inextricably intertwined in the tree: to the exclusion
of other such heirarchies.
>Many posts site the overuse of virtual functions as an evil.
I dont think I said that: I would caution against
overuse, or inappropriate use of inheritance, however.
>A wide berth is given to multiple inheritance and virtual bases.
As an advocate of mixins, which rely on multiple inheritance,
virtual bases and abstraction heavily, I dont think *I* could be
accused of that :-)
>Am I right, or is it all in my head?
>
>This is fine, there are some ways to use the language that are better than
>others. I avoid dangerous features where possible, too. The problem is that
>I don't see much to balance the negativity. In particular, where are the
>success stories that rave about the use of polymorphism (via inheritance and
>virtual functions) as a vital element in the success of the design? In
>conjunction with encapsulation, I think this is where the true power of OO
>lies.
The lack of successes is due to use of what I claim are
inappropriate techniques: in particular due to the history of C++,
which originally had only Single Inheritance, and due to the
strong influence of Smalltalk, inheritance was used to create
Object Heirarchies: and they just dont work properly: the problem
is you *cant* use virtual functions in an object heirarchy:
You either end up with a super fat base class with a virtual
function for everything, or you have to downcast. Even worse,
if you attempt to do an assignment, or copy an object at the wrong level,
your object gets sliced up.
(I'm only just beginning to realise why this is: there
is a major hole in the language)
>
>I recently completed a 2.5 year OO-designed C++ project. Despite my best
>efforts, there just wasn't much polymorphism in the system. Very few classes
>seemed to make much use of virtual functions. The class hierarchies were very
>shallow, and most seemed to exist just for implementation, not to represent
>is-a relationships.
Thats exactly correct. The 'isa' relation is exactly the
implementation of an abstraction, nothing more, nothing less.
It must not introduce extra public states to the derived object.
>The ones that did showed pretty trivial gains in
>functionality/code reduction.
These are two distinct aims. Reusing interface ('isa') and
reusing code are actually hard to do together.
>
>Now we did deliver on time and showed some pretty amazing productivity. We
>used the heck out of the ADT features of C++. But, golly, if all I wanted was
>abstract data types, I could just use Ada (please note the tone of
>exaggeration in my voice). I'm also pessimistic about how well the system can
>be reused and extended, as it was meant to be.
>
>I'm really gloomy now because I'm helping out with another project that's
>starting to shape up the same way.
>
>> Perhaps in "unlearning" some of the Smalltalk things, you
>>became much more aware *why* certain things work well in Stalk and not C++,
>>and vice versa?
>
>There's probably nothing you don't alreay know. Smalltalk has a single rooted
>hierarchy; C++ doesn't. Smalltalk is typeless; C++ is strongly typed.
>Smalltalk has GC; C++ has memory management. I admit it still mystifies me a
>great deal.
These few things add up to a big difference.
>
>But I long for that "plug and play" feel you get from Smalltalk. I want to
>write LOTS of C++ code that says, "just gimme a T*; I don't care what it
>really points to, I'll just use it to do my job!" instead of just little bits.
So why not do this? Just make the T class have virtual functions
so you can 'plug' in any implementation you want.
>
>What's my problem (be kind now...)? Is it because I'm not using a nifty COTS
>class library? Because I still haven't read Coplien or Cargill? Or have I
>just not got the hang of it yet?
No one has. Coplien doesnt even mention mixins, for example.
>
>Is there anybody out there who is doing real world C++ applications with a
>truly OO flavor? How do you do it? But please, no more GUI stories, thank
>you. We all know that a TextEditor isa ScrolledWindow isa Window isa blah
>blah blah.
>
>> Oh, that is so well said. Thank you.
>
>Stop that. You're just encouraging me. :)
>
I wrote an application that modelled a chemical plant:
it allows graphical construction of the plant, and computes risk
contours. (Fire, toxic exposure, explosions).
The risks involved depend on the chemicals, but also
the geometry of the vessels and the amount of stuff in them.
I want to have an abstract 'vessel' class to allow
the system to be extended without touching the main program.
In fact, I put the conrete classes in Windows dynamic link libraries,
so the program looks up the available types of vessels while
it is running: the contraints on this design are simple:
Each concrete vessel class must *be* an abstract vessel.
That is, I have to use the *isa* relation rigourously. There
is no way I could downcast to the derived class, because the main
program doesnt know the names of ANY of the derived classes.
Virtual function call is the only available
mechanism. C++ polymorphism. No dynamic lookup possible.
It was *REALLY HARD* to get the abstraction right so
that I could:
Create
Edit and move
Destroy
Set the dimensions
Draw on a map
Draw side view
Fill the vessel with some material to some level at some pressure
compute volume/height ratio of liquid in the vessel
compute failure points
compute failure frequencies
compute leakage rates
(and other things) for an abstract vessel: no special cases,
no hacks, no kludges: the DLL mechanism absolutely required
a genuine 'isa' relation.
It worked. (The above bit only account for, say,
petrol leaking on the ground: it hasn't even caught fire yet :-)
I also succeeded in writing an emulator for a lighting control
network, 'plug in any new device type to see how it works'.
(This was to test the design before hand coding the device's
microcontroller for real-time operation in assembler)
I hope these two things are 'real world' enough :-)
--
JOHN (MAX) SKALLER, INTERNET:max...@suphys.physics.su.oz.au
Maxtal Pty Ltd, CSERVE:10236.1703
6 MacKay St ASHFIELD, Mem: SA IT/9/22,SC22/WG21
NSW 2131, AUSTRALIA
Stephen G. Edwards
In article <1993May1.0...@ucc.su.OZ.AU> John Max Skaller,
max...@physics.su.OZ.AU writes:
>In article <1rpqj7$o...@kong.gsfc.nasa.gov> Stephen G. Edwards
>>Many posts site the overuse of virtual functions as an evil.
[etc.]
>>A wide berth is given to multiple inheritance and virtual bases.
>
> As an advocate of mixins, which rely on multiple inheritance,
>virtual bases and abstraction heavily, I dont think *I* could be
>accused of that :-)
Sorry, didn't mean to imply you in particular held these views. I was trying
to summarize observations I'd seen in various postings.
I have to say I agree. I just wanted to know what the flip side was: what's
the right way to do OOP in C++.
> The lack of successes is due to use of what I claim are
>inappropriate techniques: in particular due to the history of C++,
[...]
> (I'm only just beginning to realise why this is: there
>is a major hole in the language)
Care to elaborate?
> I wrote an application that modelled a chemical plant:
>it allows graphical construction of the plant, and computes risk
>contours. (Fire, toxic exposure, explosions).
[...]
> It was *REALLY HARD* to get the abstraction right so
>that I could:
>
> Create
> Edit and move
[etc.]
That's the realization that I'm coming to: it is really, really hard to get
the abstractions right. Which contradicts my belief that OOP can be a more
natural way to program. And as someone else pointed out to me, if it's so
hard, where does that leave all the novices that I have on my projects who
need to be productive, too? I'm beginning to think that C++ (currently)
doesn't support OOP as well as I first thought. :(
John Max Skaller
>From: John Max Skaller, max...@physics.su.OZ.AU
>
>>is a major hole in the language)
>
>Care to elaborate?
Roughly, there is no support for delegation. The support
for 're-exporting' members of a private base is limited to
'access modifiers'. What you often need to do, I *think*
(not sure!) is inherit everything *except* the base itself:
that is, you dont want to be able to upcast.
I'm still trying to figure this out, and I dont really
know the right answer.
>> It was *REALLY HARD* to get the abstraction right so
>>that I could:
>>
>> Create
>> Edit and move
>
>That's the realization that I'm coming to: it is really, really hard to get
>the abstractions right. Which contradicts my belief that OOP can be a more
>natural way to program.
No it doesnt. It was just as hard before, its just that
writing the code took so long (no reusability) that you only
faced the design problems every few weeks.
Now you face them every day. Thats how much more efficient
and natural C++ *programming* is.
The design problems remain.
>And as someone else pointed out to me, if it's so
>hard, where does that leave all the novices that I have on my projects who
>need to be productive, too?
Studying. Verifying. Testing. Designing what they can.
Documenting. Adding extra functionality to existing designed
classes (thats an excellent place for a novice to work, IMHO)
Out of a job if they cant. :-(
>I'm beginning to think that C++ (currently)
>doesn't support OOP as well as I first thought. :(
Yes it does, it supports it so well there is no programming
to do: its all high level design.
With C++ you dont *need* hack programmers: by the time
you have specified the class interface, you might as well take
the extra 10 minutes to write the code too.
I hardly spend any time implementing algorithms these days.
Most of the time is spent designing the algorithms, and then
designing the tools I need to implement the algorithm.
That is, if you see a 10 line algorithm in a book
(say the "subset construction" in the Dragon book), you should
be able to implement it in about 20 lines in C++. If you cant,
you stuffed the design: you needed to design more support
classes first.
So its almost all design work. There is little place
for mere hack programming like there was in the days of the
COBOL sweat shop.
Luckily, most programmers are pretty smart and can
do design work as well as cut code. Just look at the
type of problems people bring to this forum. Almost
all the problems are either:
1) requests for information (how to prog the mouse)
2) complaints about non-working compilers
3) design problems
Many of the design problems are *technical* design problems.
But its design all the same. With static type checking,
you have to get the design right. (Well righter :-)
When you do, the rest of the code practically writes itself :-)
(Templates *literally* do that :-)
Jim Adcock
|That's the realization that I'm coming to: it is really, really hard to get
|the abstractions right. Which contradicts my belief that OOP can be a more
|natural way to program. And as someone else pointed out to me, if it's so
|hard, where does that leave all the novices that I have on my projects who
|need to be productive, too? I'm beginning to think that C++ (currently)
|doesn't support OOP as well as I first thought.
Would it be better to give your novices a language where it was easier --
-- to get it wrong ???
Stephen G. Edwards
Obviously not, but you have to admit it's pretty easy to get it wrong in C++,
especially if you've come from a background where you didn't have to worry
about the difference between the stack and the heap, between pass by reference
and pass by value, etc. But that's besides the point.
What disappointed me was the fact that OO programming is not adequately
supported by the bare language itself. I've realized that in addition one
often needs to rely on various idioms and styles (see the "ADTs and Objects"
thread for an example). This is OK; you can use the language building blocks
to shape the programming environment the way you want it.
But that means there is yet another hill to climb once one has mastered the
basic language features before one can start producing truly OO-flavored code.
This is a drawback compared to my Smalltalk experiences, where you could
immediately jump feet first into the object paradigm. But then I'm an
(attempted) OO programmer first and a C++ programmer second. C++ just happens
to be the best all-around tool for my environment right now.
Now, let's see...Coplien, page 1...
---
Stephen G. Edwards,
NASA/Goddard Space Flight Center
Code 522.2
edw...@kong.gsfc.nasa.gov
(301) 286-6676
Robert Martin
>|That's the realization that I'm coming to: it is really, really hard to get
>|the abstractions right. Which contradicts my belief that OOP can be a more
>|natural way to program. And as someone else pointed out to me, if it's so
>|hard, where does that leave all the novices that I have on my projects who
>|need to be productive, too? I'm beginning to think that C++ (currently)
>|doesn't support OOP as well as I first thought.
I disagree slightly. It is not really hard to get the abstractions right.
It is really hard to learn how to get the abstractions right. There is
a difference. Once you have learned how to create abstractions, then
the task gets much much easier. But for the first few days/weeks/months
it can be quite a stretch of the brain.
This has nothing whatever to do with C++ as an OOP. C++'s abstractions
are no more difficult to get right than Smalltalk's. Each language
has its funny quirks and idioms.
In my opinion, learning curves are something that software engineers are
simply going to have to face. And each of us is going to have to struggle
to get to over them. Software, as an engineering practice is still
woefully immature. If we are to push it out of its adolescence and into
adulthood, we are all going to have to learn lots lots more than we know
today. OOP, and the art of creating abstractions, is just one step along
that path.
--
Robert Martin | Design Consulting | Training courses offered:
R. C. M. Consulting | uunet!rcm!rmartin | Object Oriented Analysis
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
Green Oaks, Il 60048| Fax: (708) 918-1023 | C++
John Max Skaller
>
>What disappointed me was the fact that OO programming is not adequately
>supported by the bare language itself. I've realized that in addition one
>often needs to rely on various idioms and styles (see the "ADTs and Objects"
>thread for an example). This is OK; you can use the language building blocks
>to shape the programming environment the way you want it.
There are several reasons for this. The main one is
Bjarne Stroustrup's attitude as a language designer: if you're not
sure that something is downright dangerous or useless, better
leave that facility available: who knows what some smart programmer
might use it for?
I think Bjarne has been proved right time and again
on this issue. Although it is true that one must develop
idioms to use the language sucessfully, there are a large
number of different idioms that support different styles,
the point is that no one *really* knows how to design the
'perfect' programming language.
If you like, C++ is a *meta-language* which attempts
to provide a wide variety of resources from which programming
toolkits and styles can be constructed.
I think this is one of the reasons that C++ is so
popular and successful: it is a highly adaptable language
that does not constrain the programmer to writing
object oriented code in some style, in fact, it doesnt constrain
the programmer to writing object oriented code at all :-)
>
>But that means there is yet another hill to climb once one has mastered the
>basic language features before one can start producing truly OO-flavored code.
That depends how you learn the language.
> This is a drawback compared to my Smalltalk experiences, where you could
>immediately jump feet first into the object paradigm. But then I'm an
>(attempted) OO programmer first and a C++ programmer second. C++ just happens
>to be the best all-around tool for my environment right now.
>
>Now, let's see...Coplien, page 1...
>
Be careful with Coplien. When it says 'Advanced' it means it.
Many of the idioms are *too* advanced, that is, they are well
into the area of 'experimental' design and research level techniques.
Also, Coplien doesn't mention mixins :-)
Robert Martin
>In article <1993May04.1...@microsoft.com> Jim Adcock,
>ji...@microsoft.com writes:
>>In article <1s379h$8...@kong.gsfc.nasa.gov> Stephen G. Edwards
>><edw...@kong.gsfc.nasa.gov> writes:
>>|That's the realization that I'm coming to: it is really, really hard to get
>>|the abstractions right.
>>...
>>|I'm beginning to think that C++ (currently)
>>|doesn't support OOP as well as I first thought.
>>Would it be better to give your novices a language where it was easier --
>> -- to get it wrong ???
>>
>Obviously not, but you have to admit it's pretty easy to get it wrong in C++,
>especially if you've come from a background where you didn't have to worry
>about the difference between the stack and the heap, between pass by reference
>and pass by value, etc. But that's besides the point.
No, that's precisely the point. C++ does not resemble Smalltalk. But
that doesn't mean that it is any harder to get the abstractions right
in C++. It also doesn't mean that OO is any harder in C++. It just
means that the languages are dissimilar and that you are having trouble
making the transition.
>What disappointed me was the fact that OO programming is not adequately
>supported by the bare language itself.
What definition of "OO programming" are you invoking here? C++ supports
inheritance and late binding quite nicely. it also supports a plethora
of other features which are more ancillary to OO.
>But that means there is yet another hill to climb once one has mastered the
>basic language features before one can start producing truly OO-flavored code.
> This is a drawback compared to my Smalltalk experiences, where you could
>immediately jump feet first into the object paradigm.
Perhaps you remember your "jump into Smalltalk" with fond memories. Although
I love Smalltalk, I did not find it trivial to learn. And then when I learned
C++ I had a similar conceptual hurtle to make. They are very different
languages. But given the choice today, I would pick C++ for industrial
strength code.
>But then I'm an
>(attempted) OO programmer first and a C++ programmer second. C++ just happens
>to be the best all-around tool for my environment right now.
Nor is that likely to change in the near future.
Stephen G. Edwards
rma...@uunet.uu.net!rcm (Robert Martin) wrote:
>
> Stephen G. Edwards <edw...@kong.gsfc.nasa.gov> writes:
> >Obviously not, but you have to admit it's pretty easy to get it wrong in C++,
> >especially if you've come from a background where you didn't have to worry
> >about the difference between the stack and the heap, between pass by reference
> >and pass by value, etc. But that's besides the point.
I say this is besides the point because I don't mean to argue C++ features
vs. Smalltalk features. They are quite dissimilar in many respects.
> No, that's precisely the point. C++ does not resemble Smalltalk. But
> that doesn't mean that it is any harder to get the abstractions right
> in C++. It also doesn't mean that OO is any harder in C++. It just
> means that the languages are dissimilar and that you are having trouble
> making the transition.
There is no "transition," really. I've been programming C++ for five
years. Prior to that I only used Smalltalk for the equivalent of a few
weeks.
I apologize that my comments have led in this direction. I am in no way
trying to slam C++. I'm a C++ advocate.
My original intent was not to comment on the adequacy of the language. I
admit my level of sophistication is not sufficient for that task.
I have had a great deal of success using C++ to create concrete,
user-defined data types that can to a great extent be treated like built-in
types. This is how I interpret the phrase "using C++ like a better C."
I have not had as much success introducing object-oriented techniques into
my systems. By this I primarily mean polymorphism, which in large part can
provide for the flexibility and extensibility of a system, and for which
C++ requires the use of inheritance.
As I interpret the discussion here and in other threads, it is not enough
to take the design diagrams on your blackboard (e.g., Booch) and write
classes that represent those relationships directly. It seems to be
necessary to use idioms to produce components that are both object-oriented
and robust. One may say that I am not using the right diagrams, but this
just begs the question.
And the original question was and still is, what is the proper approach to
using the features of C++ to achieve a high degree of polymorphic
abstraction in the components of a system? I've learned a great deal from
the discussion so far, but I'd like to hear even more thoughts directed at
that point.
John Max Skaller
>
>I have had a great deal of success using C++ to create concrete,
>user-defined data types that can to a great extent be treated like built-in
>types. This is how I interpret the phrase "using C++ like a better C."
An excellent technique!
>
>I have not had as much success introducing object-oriented techniques into
>my systems. By this I primarily mean polymorphism, which in large part can
>provide for the flexibility and extensibility of a system, and for which
>C++ requires the use of inheritance.
There are other ways. Such as delegation and using function
pointers (both of which are more powerful than using virtual functions)
>
>As I interpret the discussion here and in other threads, it is not enough
>to take the design diagrams on your blackboard (e.g., Booch) and write
>classes that represent those relationships directly. It seems to be
>necessary to use idioms to produce components that are both object-oriented
>and robust. One may say that I am not using the right diagrams, but this
>just begs the question.
If the diagrams had the same level of detail as the
actual classes needed, why would you bother with the diagrams
when you could write class interfaces in a formal language
that could be statically type checked? Diagrams are a guideline:
a thought tool.
>
>And the original question was and still is, what is the proper approach to
>using the features of C++ to achieve a high degree of polymorphic
>abstraction in the components of a system?
You are already using it. Dont panic! Write C with classes.
Thats what C++ is. With time, your library of classes will grow
and be refined, and it will become easier to devise more
higher level classes. You will start trying to unify the classes
by eliminating repeated patterns, and polymorphism will just happen
for you :-)
Eventually more and more of each application will be
built using classes, and you will strike a balance between
functional/procedural C style with user defined ADT classes
and object oriented polymorphic techniques.
Experiment by all means but dont go overboard
or your projects will crash and burn: C++ is not a pure
object oriented language and does not provide the full support
needed for that style (you have to provide it yourself).
Witness the discussion about Garbage Collection:
Stroustrup says it will come but we're not ready yet.
Premature adoption of advanced techniques can be disasterous.
>I've learned a great deal from
>the discussion so far, but I'd like to hear even more thoughts directed at
>that point.
The best way to get into using polymorphism, IMHO,
is to write classes that look general, then split the class
into two classes:
AbstractClass
ConcreteClass : public virtual AbstractClass
but dont do that until you need to add
ConcreteClass2 : public virtual AbstractClass
because only then do you have an objective way of determining
that you have an Abstraction that generalises anything.
Concrete classes derived from abstract ones are
very likely to be proper subclasses. Make sure your
program *only* works with the AbstractClass, except of
course when you construct an object.
James Kanze
rma...@uunet.uu.net!rcm (Robert Martin) writes:
|> What definition of "OO programming" are you invoking here? C++ supports
|> inheritance and late binding quite nicely. it also supports a plethora
|> of other features which are more ancillary to OO.
There is one thing that I find hard to do in C++, and that I think is
important for OO coding: how do you return a synthesized polymorphic
value?
All other OO languages that I know use reference semantics and garbage
collection. So in fact, all objects are created on the heap, and only
references are passed around. This would not be difficult to simulate
in C++ (a bit of extra typing), but it will only work in the presence
of garbage collection. So IMHO, as long as C++ has no garbage
collection, it cannot pretend to be a true OO language, but only a
general programming language with a lot of OO features.
Note that this is not necessarily that bad; the fact that it is also a
general programming language (and not *just* an OO language) is one of
C++'s strong points. But I would like to see garbage collection
added, to clear up the above weakness. (I would also like to see some
sort of syntax extension to tell the compiler to handle the class as a
reference rather than a value, but this is of much lower importance,
as it is easily simulated.)
--
James Kanze email: ka...@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
James Kanze
max...@physics.su.OZ.AU (John Max Skaller) writes:
|> If you like, C++ is a *meta-language* which attempts
|> to provide a wide variety of resources from which programming
|> toolkits and styles can be constructed.
This may be the best description of C++ I've heard yet. There are
better languages for pure OO programming, and there are better
languages for writing ADT's, and there are better languages for doing
hardware level programming, and... But you can do it all in C++.
On the other hand, this particular flexibility does not make the
language easier to learn.
I think generally that one should start out learning just a sub-set of
the language, and expand on it. Which sub-set is chosen may depend on
what your programmers want and/or need, ie: people with experience
will probably be able to take on inheritence right from the start, but
may have problems with some other concepts that are "obvious" to ex-C
programmers (no example, as I don't know Smalltalk myself). So how
you organize this will depend on your people.
I might add that one of the best ways of transfering know-how (once
you've got a guru or two) is code review. It has always amazed me how
fast people will pick up the fine points of the language once they see
real cases in their problem domain.
John English
: [... some stuff ...] But I would like to see garbage collection
: added, to clear up the above weakness. (I would also like to see some
Can we garbage collect the garbage collection issue into a garbage collection
thread now please? It seems to be spilling over from "C++ bashers..." (?)
into everywhere else... (all together now, RTTI RTTI tum tah tum!)
--
-------------------------------------------------------------------------------
John English | "There are basically two types of dicks,
Dept. of Computing | hard dicks and floppy dicks."
University of Brighton | -- from a student essay on storage media
E-mail: j...@unix.brighton.ac.uk | "Disks are divided into sex & tractors."
Fax: 0273 642405 | -- from one of my lectures (on a bad day)
-------------------------------------------------------------------------------
John Max Skaller
>In article <1993May6.1...@uunet.uu.net!rcm>
>rma...@uunet.uu.net!rcm (Robert Martin) writes:
>
>|> What definition of "OO programming" are you invoking here? C++ supports
>|> inheritance and late binding quite nicely. it also supports a plethora
>|> of other features which are more ancillary to OO.
>
>There is one thing that I find hard to do in C++, and that I think is
>important for OO coding: how do you return a synthesized polymorphic
>value?
>
Right. How do you make an ADT which is an Object?
Coplien describes various delegation techniques.
Kent Budge suggested that the way to do it involved an ADT class
that 'represents' the abstract Object class.
I'm claiming credit for inventing this name for that:
"Carrier Pigeons" (couldnt resist)
So you dont return a reference, you return a *representative*
which has the power to delegate to the abstract object. It also
has to delete it when appropriate (use reference counting or
something better)