Gang of Four book useless, composition > inheritance

[RayLopez99]

see this thread: http://c2.com/cgi/wiki?CompositionInsteadOfInheritance

Of particular interest note this statement:
"CompositionInsteadOfInheritance is somewhat related to
DelegationIsInheritance. It also tends to reflect implicit cultural
assumptions. For some reason (perhaps simple history), the American OO
community has always tended to think in terms of Inheritance and
Specialization. This may reflect the influence of early and naive
Smalltalk activity. The European OO community, conversely, has always
tended to think in terms of Delegation and Composition."

Also the Gang of Four book design patterns, which are interesting and
I'm going through now, I think are rarely used outside of libraries.
I mean I never use anything much more than the "Composite" design
pattern. But they are good to go through, as programming exercises.

RL

 

[Registered User]

see this thread: http://c2.com/cgi/wiki?CompositionInsteadOfInheritance

Of particular interest note this statement:
"CompositionInsteadOfInheritance is somewhat related to
DelegationIsInheritance. It also tends to reflect implicit cultural
assumptions. For some reason (perhaps simple history), the American OO
community has always tended to think in terms of Inheritance and
Specialization. This may reflect the influence of early and naive
Smalltalk activity. The European OO community, conversely, has always
tended to think in terms of Delegation and Composition."

What makes the quote notable? The comparison of inheritance and
composition patterns attempts to explain how to choose which of the
two patterns is more suitable for a specific task. There is no
judgment or controversy about one pattern being universally better
than the other.

For the specific example a roles and membership pattern presents a
third option.

Also the Gang of Four book design patterns, which are interesting and
I'm going through now, I think are rarely used outside of libraries.
I mean I never use anything much more than the "Composite" design
pattern. But they are good to go through, as programming exercises.

The GoF text only covers a few specific design patterns. As abstract
concepts not all design patterns are named, published or universally
recognized. Many designers and programmers don't have the abstraction
skills necessary to recognize the patterns they repeatedly use.

There is no point in attempting to discuss design patterns in this
thread with the OP. The unfounded speculation concerning both the
usage and value of design patterns precludes any sort of rational
discussion.

regards
A.G.

 

[Willem van Rumpt]

Of particular interest note this statement:
"CompositionInsteadOfInheritance is somewhat related to
DelegationIsInheritance. It also tends to reflect implicit cultural
assumptions. For some reason (perhaps simple history), the American OO
community has always tended to think in terms of Inheritance and
Specialization. This may reflect the influence of early and naive
Smalltalk activity. The European OO community, conversely, has always
tended to think in terms of Delegation and Composition."

The historical part analysis I find mildly interesting; other than that
I can't find anything remotely interesting about the quote.

Also the Gang of Four book design patterns, which are interesting and
I'm going through now, I think are rarely used outside of libraries.
I mean I never use anything much more than the "Composite" design
pattern. But they are good to go through, as programming exercises.

In the sources I have to go to professionally (old and new), I find lots
of the patterns get used very frequently, but mostly implicitly, i.e.
without the original author being aware of it, or having to be aware of
it. This makes it a pattern none the less though.

It's pretty straightforward to "implement" a strategy, visitor, factory,
or, quite frankly, lots of the designs in the book, without ever having
read the GoF Design Patterns; lots of them emerge as you write code,
though they might present them to you as such.

To my mind then, the point of the book is not to introduce the patterns,
but to formalize them, help people recognize them. Identify, explain,
and document common patterns, and match them with real life software
design problems that they might help solve. I would say this is A Good
Thing (tm).

In any serious construction and/or engineering field, this is completely
normal, accepted, and, I dare say, mandatory.

 

[Arne Vajhøj]

In the sources I have to go to professionally (old and new), I find lots
of the patterns get used very frequently, but mostly implicitly, i.e.
without the original author being aware of it, or having to be aware of
it. This makes it a pattern none the less though.

It's pretty straightforward to "implement" a strategy, visitor, factory,
or, quite frankly, lots of the designs in the book, without ever having
read the GoF Design Patterns; lots of them emerge as you write code,
though they might present them to you as such.

To my mind then, the point of the book is not to introduce the patterns,
but to formalize them, help people recognize them. Identify, explain,
and document common patterns, and match them with real life software
design problems that they might help solve. I would say this is A Good
Thing (tm).

In any serious construction and/or engineering field, this is completely
normal, accepted, and, I dare say, mandatory.

As I see it then the patterns documentation has two benefits:
* it allows for short but still very precise descriptions - if
some docs say "GoF XXXX pattern" then the readers knows
(or should know) exactly what is meant - without patterns
with known names it would require a half page of pseudo code
to communicate the same content
* it allows new developers to jump start - instead of experimenting for
20 years and end up with the same patterns they can now read about
them and after first actual usage be up to speed

Arne

 

[Arne Vajhøj]

see this thread: http://c2.com/cgi/wiki?CompositionInsteadOfInheritance

Of particular interest note this statement:
"CompositionInsteadOfInheritance is somewhat related to
DelegationIsInheritance. It also tends to reflect implicit cultural
assumptions. For some reason (perhaps simple history), the American OO
community has always tended to think in terms of Inheritance and
Specialization. This may reflect the influence of early and naive
Smalltalk activity. The European OO community, conversely, has always
tended to think in terms of Delegation and Composition."

Also the Gang of Four book design patterns, which are interesting and
I'm going through now, I think are rarely used outside of libraries.
I mean I never use anything much more than the "Composite" design
pattern. But they are good to go through, as programming exercises.

I think you should reconsider your coding style.

Many of the GoF patterns are used frequently.

Abstract Factory, Factory, Singleton, Adapter, Decorator, Facade, Proxy,
Command, Iterator, Observer, State, Strategy, Visitor are
all used frequently in my experience.

Arne

 

[Willem van Rumpt]

As I see it then the patterns documentation has two benefits:
* it allows for short but still very precise descriptions - if
some docs say "GoF XXXX pattern" then the readers knows
(or should know) exactly what is meant - without patterns
with known names it would require a half page of pseudo code
to communicate the same content
* it allows new developers to jump start - instead of experimenting for
20 years and end up with the same patterns they can now read about
them and after first actual usage be up to speed

Exactly my sentiment: Listing, describing, and documenting elemental
building blocks of object oriented programming; simply providing a basic
set of construction elements, with guidance on how, when, and where they
can be applied.

It's not even new (the book is close to being around for two decades, as
far as I know). And inthat time it gained the status of *the* book to
learn and read about common patterns.

Very benificial for both beginning and seasoned programmers, I would say.

 

[RayLopez99]

There is no point in attempting to discuss design patterns in this
thread with the OP. The unfounded speculation concerning both the
usage and value of design patterns precludes any sort of rational
discussion.

Projection noted. Thanks for sharing with us your state (closed) of
mind.

RL

 

[RayLopez99]

Many of the GoF patterns are used frequently.

Outside of a library?

Abstract Factory, Factory, Singleton, Adapter, Decorator, Facade, Proxy,
Command, Iterator, Observer, State, Strategy, Visitor are
all used frequently in my experience.

You write library routines?

In frequency of use, according to the DoFactory people:

Abstract Factory = HIGH
Factory = HIGH
Singleton = MEDIUM HIGH
Adapter = MEDIUM HIGH
Decorator = MEDIUM
Facade = HIGH
Proxy = MEDIUM HIGH
Command = MEDIUM HIGH
Iterator = HIGH
Observer = HIGH
State = MEDIUM
Strategy = MEDIUM HIGH
Visitor = LOW

AHAHAHAHA! You use "Visitor" which DoFactory says has a low frequency
of use. I knew there was something wrong with your post and found it.

RL

 

[Arne Vajhøj]

Outside of a library?
Yes.


You write library routines?

Library and other code.

In frequency of use, according to the DoFactory people:

Abstract Factory = HIGH
Factory = HIGH
Singleton = MEDIUM HIGH
Adapter = MEDIUM HIGH
Decorator = MEDIUM
Facade = HIGH
Proxy = MEDIUM HIGH
Command = MEDIUM HIGH
Iterator = HIGH
Observer = HIGH
State = MEDIUM
Strategy = MEDIUM HIGH
Visitor = LOW

AHAHAHAHA! You use "Visitor" which DoFactory says has a low frequency
of use. I knew there was something wrong with your post and found it.

I have seen Visitor used.

Obviously I am not that big a sample.

But may I point you to:

http://www.artima.com/cppsource/top_cpp_aha_moments.html

Arne

 

[RayLopez99]

Library and other code.












I have seen Visitor used.

Obviously I am not that big a sample.

But may I point you to:

http://www.artima.com/cppsource/top_cpp_aha_moments.html

Arne

It's interesting that Scotty Meyers, a famous author, makes this
statement:

"I’ll begin with what many of you will find an unredeemably damning
confession: I have not written production software in over 20 years,
and I have never written production software in C++. Nope, not ever.
Furthermore, I’ve never even tried to write production software in C+
+, so not only am I not a real C++ developer, I’m not even a wannabe.
Counterbalancing this slightly is the fact that I did write research
software in C++ during my graduate school years (1985-1993), but even
that was small (a few thousand lines) single-developer to-be-thrown-
away-quickly stuff. And since striking out as a consultant over a
dozen years ago, my C++ programming has been limited to toy “let’s see
how this works” (or, sometimes, “let’s see how many compilers this
breaks”) programs, typically programs that fit in a single file.
(make? Who needs stinkin’ make?) My living is based on C++, but it’s
not by virtue of the programs I write in it. "

Do as I say, not as I do. Or those that can, do, those that can't,
teach.

RL

 

[Arne Vajhøj]

It's interesting that Scotty Meyers, a famous author, makes this
statement:

"I’ll begin with what many of you will find an unredeemably damning
confession: I have not written production software in over 20 years,
and I have never written production software in C++. Nope, not ever.
Furthermore, I’ve never even tried to write production software in C+
+, so not only am I not a real C++ developer, I’m not even a wannabe.
Counterbalancing this slightly is the fact that I did write research
software in C++ during my graduate school years (1985-1993), but even
that was small (a few thousand lines) single-developer to-be-thrown-
away-quickly stuff. And since striking out as a consultant over a
dozen years ago, my C++ programming has been limited to toy “let’s see
how this works” (or, sometimes, “let’s see how many compilers this
breaks”) programs, typically programs that fit in a single file.
(make? Who needs stinkin’ make?) My living is based on C++, but it’s
not by virtue of the programs I write in it. "

Do as I say, not as I do. Or those that can, do, those that can't,
teach.

I am pretty sure that he can.

But if he make more money teaching people how to do it than by
doing himself, then ...

Arne