Re^3: MJD's "Design Patterns Aren't"

To be fair I don't think that's the fault of the book or its authors - but the fault of some peoples reading of the book.

Possibly, but their insistence on OO only solutions, even in C++ where others are available, didn't help. It's been a while since I read the book, but I don't remember them presenting multiple implementations for each pattern. They definitely didn't say, "Here's how you do it with objects and here's how you do it without."

Don't take any of that to mean I don't respect their book. I learned a lot from it. In particular the problems they are trying to solve, and their descriptions of them, have greatly improved my skill in medium to large scale design. I just reject their school of thought when it insists on OO only and their followers when they insist that any implementation of a solution to one of the GoF problems must mimic the one in the book. Which leads back to your point about the people reading the book, who certainly must shoulder a lot of blame.

Phil

Comment on Re^3: MJD's "Design Patterns Aren't"

Replies are listed 'Best First'.
Re^4: MJD's "Design Patterns Aren't" by adrianh (Chancellor) on Jul 16, 2006 at 14:15 UTC
Possibly, but their insistence on OO only solutions, even in C++ where others are available, didn't help. It's been a while since I read the book, but I don't remember them presenting multiple implementations for each pattern. It's already a pretty thick book :-) It's a fair criticism I guess - but picking implementation examples in languages that the majority of readers would be familiar with would seem a reasonable choice. The problem is that all some people seem to get from the books are those examples - not that nice bit of text preceding it that talks about why and where you should and should not use the pattern. And a bunch of them are OO design patterns. So what? The book isn't the definitive list of all design patterns for all languages and methodologies - and the authors were pretty darn clear about that as I recollect. Unfortunately there seem to be a large chunk of people incapable of understanding this :-( I just reject their school of thought when it insists on OO only and their followers when they insist that any implementation of a solution to one of the GoF problems must mimic the one in the book. God yes. Huge pains the arse. However, just as bad are the ones who reject everything from the book because "Perl has arrays/foreach" - conveniently ignoring that there's a lot more in the GoF book than just the iterator pattern, and that there are still a bunch of places you do want to use the iterator pattern instead of an array.	[reply]

Replies are listed 'Best First'.

Re^4: MJD's "Design Patterns Aren't"
by adrianh (Chancellor) on Jul 16, 2006 at 14:15 UTC

Possibly, but their insistence on OO only solutions, even in C++ where others are available, didn't help. It's been a while since I read the book, but I don't remember them presenting multiple implementations for each pattern.

It's already a pretty thick book :-)

It's a fair criticism I guess - but picking implementation examples in languages that the majority of readers would be familiar with would seem a reasonable choice. The problem is that all some people seem to get from the books are those examples - not that nice bit of text preceding it that talks about why and where you should and should not use the pattern.

And a bunch of them are OO design patterns. So what? The book isn't the definitive list of all design patterns for all languages and methodologies - and the authors were pretty darn clear about that as I recollect. Unfortunately there seem to be a large chunk of people incapable of understanding this :-(

I just reject their school of thought when it insists on OO only and their followers when they insist that any implementation of a solution to one of the GoF problems must mimic the one in the book.

God yes. Huge pains the arse.

However, just as bad are the ones who reject everything from the book because "Perl has arrays/foreach" - conveniently ignoring that there's a lot more in the GoF book than just the iterator pattern, and that there are still a bunch of places you do want to use the iterator pattern instead of an array.

[reply]