Rick DeNatale wrote:
I strongly believe that although there might be a few universal truths, most
good OO design needs to take the characteristics of the language into
account. If you learn OO from a Java tutorial, you’re going to speak Ruby
with a Java accent.
Very true, and I’m glad to see this point made.
Object Oriented Software Construction will leave you
with an Eiffel accent. The Gang of Four Design Patterns book, although it
purports to be “language neutral” at least for the popular OO languages back
in 1995, is strongly influenced by C++.
???
The GoF book has strong influences from Smalltalk and Java. C++ OO is a
completely different beast. The GoF don’t even mention templates, nor
static polymorphism.
Most self-proclaimed “pure OO” schools of thought represent only
Smalltalk-style OO, based heavily on runtime indirection. UML only
supports templates as a kind of necessary evil, and still lacks any
support for concepts (where “concept” is a technical term, with a
specific meaning in C++). The GoF book is in this vein.
Bare C++ has far less support for OO at runtime than (say) Ruby, but
dramatically better support at compile-time. For example, whereas
multiple inheritance is kind of a dark art in most OO schools of
thought, C++ has wonderful support for it, and deals very cleanly with
reconvergent inheritance hierarchies (“diamonds”). If you come from a
OO background, and want to learn C++, the best way is to temporarily
forget everything you thought you knew about OO.
Btw, a related topic came up today in comp.lang.c++, about translating
GoF terminology to C++. I mentioned an example that fits, IMO, the
decorator pattern: An output iterator performs a given operation on
each output value, then passes the result to another, underlying
iterator. In GoF terminology, Component, the ConcreteComponents,
Decorator, and the ConcreteDecorators are all “classes.” In the C++
implementation, though, Component is the OutputIterator concept, the
ConcreteComponents are the specific types of the underlying iterators,
the Decorator is a template (parameterized by ConcreteComponent and by
the operation to be performed on output values), and all
ConcreteDecorators are instantiations of the template.