Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Design Patterns Considered Harmful

by dws (Chancellor)
on Dec 20, 2001 at 08:17 UTC ( #133399=perlmeditation: print w/replies, xml ) Need Help??

I've learned the hard way over the past several years that when you see the Design Patterns book show up on a junior developer's desk, you need to watch them very, very carefully for the next six months. Otherwise, you'll turn around one morning and discover a set of Builder pattern classes, flanked by Facades, sitting in the middle of what should have been a simple object model. Something about that book tickles an urge to build. It is like a box full of shiny power tools, all crying "play with me! use me!" Patterns start popping up like warts, complicating otherwise simple regions of code. And unlike ordinary messy code, this is messiness at the structural level. It costs a lot more to undo. And yes, this can even happen in Perl-based systems.

I really do like the book. It lays out a taxonomy of reusable design and implementation elements that I've reached for, judiciously, many times. Lots of problems are solved quite flexibly using a Strategy pattern. Template methods can reduce coupling. In good hands, design patterns are a powerful tool. But the chaos in that book's wake caused by immature developers can be enormous.

So my recommendation is that if you see Design Patterns appear on someone's desk, and you're not confident in their judgement, start checking in with them more often. Ask them how they like the book, and where they're seeing opportunities to use design patterns. Then talk them out of half of those "opportunities". Your code base will thank you.

And if you're not sure you're ready for the book, I say go for it. It's a great book. Just watch yourself. If you feel yourself making excuses for going out of your way to use a design pattern, stop, take a deep breath, and ask someone you trust for advice.

Replies are listed 'Best First'.
Re: Design Patterns Considered Harmful
by chromatic (Archbishop) on Dec 20, 2001 at 10:39 UTC
      Ah, Extreme Programming. From one of the Extreme Programming FAQs:

      What does YAGNI mean?
      "You aren't gonna need it," a general refrain when someone suggests building functionality for the system that isn't required by any current user story. For example:

      Programmer 1: "It says here we need to save the default number of widgets between sessions. I'd better write a generalized object persistence mechanism."

      Programmer 2: "YAGNI. Just write out a one-line text file for now. If we need more later, we'll add it later."

      Hey patterns are cool. But most often, YAGNI.
Re: Design Patterns Considered Harmful
by Voronich (Hermit) on Dec 20, 2001 at 18:10 UTC
    Strictly speaking, I can't disagree with you at all. Patternitis has (or had, it may have blown over by now) become a serious problem in dev shops. I'm primarily a C++ weenie. People call me a "senior" programmer, but whatever. I've got a couple people working with me and they LOVE nothing more than to show me how nice all their pattern usage is.

    But I have to say I've eaten up all the DP books and papers I could, finding that they're delightful keys to large-scale design and even small scale when I know I'm looking at boilerplate structure that 'smells' reusable even though it doesn't look it (even though most of them are pedantic pieces of crap.) Usually I can look around and re-browse through pattern catalogs until I see someone who's rephrased my problem. So I can't sell it short.

    The DP thing in general seems to me to show that there is a certain critical mass in code size, after which you need to really think deeply about higher-order structural organization and does so by demonstration rather than just saying "reduce, reuse, recycle" over and over again.

    BUT, there are people floating around the DP mailing lists who believe that every single line of code should be a part of a pattern and that a project should be able to be described completely in terms of patterns. (These are people who seem to spend a great deal more time writing papers than designing systems.) And it never ceases to amaze me how hard people will try to MAKE their code fir into a pattern. (This is regrettably true whether the coder is a newly formed DP convert or not.)

    Design Patterns: A force so great it can only be used for Good or Evil.

Re: Design Patterns Considered Harmful
by hding (Chaplain) on Dec 20, 2001 at 19:20 UTC
Re: Design Patterns Considered Harmful
by Steve_p (Priest) on Dec 20, 2001 at 23:05 UTC
    I definitely agree with that. I was one of those junior developers who picked up that book. All I could see were the patterns. What newbie wouldn't want to say, "I created a new Singleton Abstract Factory." ?!? It seemed as if Patterns started sprouting from every orifice.
    Being slightly older and wiser, I have now learned to apply the patterns correctly. Now using patterns simply is a guide, I've been able to cut my OO design time significantly. Rather than sometimes going into a very deep think to solve a design problem, or worse yet, designing myself into a corner, I can usually, and rather quickly, come up with the pattern that will properly apply to the system I'm designing. Its also helped with coming up with designs that strongly encourage code reuse.
    I highly recommend Design Patterns, but the reader must must have a lot of common sense or a good amount of experience to get the full affect of this book. Reading it because "Patterns are kewl!" will likely lead to poorly designed programs and heartache when you try to fix them.
      I really hate to say it this way. (Ok, maybe not.) But the approach that's worked best for me has been to immerse myself in all the "literature" (a term I use VERY loosely) then just forget it all and do design.

      Going back and looking later, the organization looks familiar.




Re: Design Patterns Considered Harmful
by hsmyers (Canon) on Dec 20, 2001 at 23:43 UTC
    I'd say that this is itself a 'Meta' pattern. You could have just as easily said the same thing about objects as patterns. And 'Structure' before that come to think of it. All kinds of koans, err—maxims come to mind, but I'd sum it all up by saying that the job of the beginner is to explore and that the job of the experienced is to go find the missing novices.


    "Never try to teach a pig to sing…it wastes your time and it annoys the pig."

      You could have just as easily said the same thing about objects as patterns.

      Right on. I once worked for a project manager who couldn't make it two sentences without saying 'object'. He was very fond of patterns as well, and seemed to believe that if he made everything object oriented and utilized patterns then the project would succeed. 'Scalable' was the other word he loved: imagine a multithreaded server (in C++ for efficiency!) for sending messages over wireless networks. Never mind that all the messages went out ONE network device!!

      Well, guess what, not only did the software not work reliably, but it became an example of how not to build that type of system.

      No question there are clear advantages to OO programming and the incorporation of some design patterns; the real problem is believing that they are a panacea. A good dose of The Mythical Man-Month I think would be a sufficient countermeasure to OO/DP fixation.

      Now if you want a really painful read, try Patterns of Software by Richard Gabriel. 200 pages of tedious speculation on the qualities of "good" software, which ultimately turns out to be the question of what constitutes objective beauty. He ends of up calling this thing "the quality without a name" and can only gesture at it with obscure utterances like "A system has this quality when it is at peace with itself, when it has no internal contradictions ... when it is true to its own inner forces". Now, I majored in Philosophy, and so talk like this strikes a chord with me, but by god, this doesn't help much when you're staring down an Emacs buffer!

        The virulent nature of memetic virus that is DP still astounds me.

        The whole "Quality Without A Name" thing is a favorite DP'er pull right from Christopher Alexander, a "real" architect who wrote "A Pattern Language", one of a series of books talking about form, function, and 'objective aesthetics' as it were.

        If you're into heady abstract reading then I'd highly recommend it. If you're not, then I'd say avoid it at all costs.

        - V


I have recognized that weakness for mine own.
by elbie (Curate) on Dec 22, 2001 at 21:50 UTC
    I am shamed to say that I knowingly suffer from that affliction.

    I've noticed a tendancy to over use some newly discovered aspect of perl that I think kewl.

    If you go back and look at all my code from a couple of months ago, you see some over use of references all over the place. I imagine that if you look at my code in the next couple of months, you'll see whatever new thing I stumble upon next.

    So, what's really cool about perl? ;)


      I do the same thing. I think it is good. The more you use something, the better your chances are that you will remember to use if further down the road. You can probably now do a reference without having to look anything up. Just as long as your code improves, you'll probable not have many troubles.

      A coworker of mine who's been picking Perl up for the past year just mentioned that. She comes from a VB background and said "I just grokked hashes about a month ago, and now everything I write has hashes in it." I remember doing the same thing, until I had enough tools to actually pick the right one at hand.

      If all you know how to use is a hammer, everything you're required to do has to be a nail.

      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Re: Design Patterns Considered Harmful
by Anonymous Monk on Dec 28, 2001 at 06:28 UTC
    The book is essentially "Computer Programming for Dummies" without actually having the honesty to title it as such. (There probably is a "dummies" book for programming by now; I'd rather not know about it.)

    There is not one "design pattern" in that book which isn't obvious, intuitive, or flat out trivial to anyone who has written more than a few hundred lines of code.

    Alot of the "OO"/DP mentality is the "discovery" that most computer programming work is highly repetitive and generally uncreative. What is left unspoken is that this is true *ONLY* because people continually ask the same "questions" of the computer again and again. Thus the "patterns" emerge: what else can one expect but the same solutions to arise when the same questions are asked?

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://133399]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2023-09-24 11:21 GMT
Find Nodes?
    Voting Booth?

    No recent polls found