in reply to MJD's "Design Patterns Aren't"

I think the point of the talk was that the original idea of patterns was to describe a common language for talking about issues that needed resolving, but that that has been perverted by a fixation on particular implementations of particular solutions to the general problems. It's not that we don't have the same problems to solve, just because we use Perl. But, it is often the case the that our implementations are radically different than those proposed by the patterns movement people, and many of our implementations are simpler because of Perl. Which is an ironic indication of how important the general problems are, after all why are there such clean implementations in Perl? Surely not because the general problems are unimportant.

The pity is that the patterns idea was subverted into an object only approach to implementations of the named patterns in the GoF book. This is bad not just because the particular implementations in that book -- and in other patterns movement resources -- are not applicable to Perl, but because the focus has shifted from talking about general problems to talking about particular solutions. We happen to notice this shift more, because the resulting solutions are so poorly shaped for our favorite language.

Phil

Replies are listed 'Best First'.
Re^2: MJD's "Design Patterns Aren't"
by adrianh (Chancellor) on Jul 14, 2006 at 12:23 UTC
    The pity is that the patterns idea was subverted into an object only approach to implementations of the named patterns in the GoF book.

    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.

[reply]
      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

[reply]
        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]

In Section Meditations