Forgot your password?
typodupeerror
Software Science

'Design Patterns' Receives ACM SIGPLAN Award 223

Posted by timothy
from the good-idea-guys dept.
bth writes "ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
This discussion has been archived. No new comments can be posted.

'Design Patterns' Receives ACM SIGPLAN Award

Comments Filter:
  • by putko (753330) on Saturday July 30, 2005 @08:12PM (#13205067) Homepage Journal
    As mentioned by Paul Graham [paulgraham.com], in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp. [norvig.com]
    • As mentioned by Paul Graham, in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.

      If I could make a decent living coding in Lisp, I might actually give a shit.

    • I must admit that I have never programmed in Lisp (my functional languages experience is limited to ML), but I would bet a substantial sum that there are at least a few idioms in Lisp that could be considered analogous to the OO design patterns that an OO language makes invisible.
      • Of course :-)

        Language bigots always think they're language is perfect. They even seek out its imperfections just so they can figure out how to recast them as perfections instead. Language bigots are among the most prickly people. Even moreso than editor or OS bigots. Prick them and they explode.

        Lisp is a great language, but it's not suitable for most mainstream programming tasks. Sorry, but it's not.
        • by shmlco (594907) on Saturday July 30, 2005 @10:08PM (#13205472) Homepage
          I just can't help myself given that sentence. To quote, "Language bigots always think they're language is perfect."

          Yes, language bigots always think THEY ARE language is perfect.

        • What's your reasoning behind the assertion that Lisp isn't suitable for most "mainstream programming tasks". Just saying it doesn't make it true.

          I don't think any real Lisp user will tell you that Lisp is perfect. There is a litany of complaints your average Lisp user has about the language (even Paul Graham). However, most will tell you that its definitely better than what exists in the mainstream. Lisp users are kind of like Linux users in that way, actually. Feature for feature, mainstream languages just
          • The best evidence is the dearth of mainstream applications written in lisp. By "mainstream" I don't mean commercial, I mean some application or utility a non-programmer would use.

            For a language that's as old and as evangelized and as well liked as lisp, this is very strange.
          • Listen to Python or Ruby folks talk about how much more productive they are in those languages versus Java or C++. There is a reason for that. It's because those languages are more like Lisp.

            Well, yes, that's sort of true in a roundabout way. Since Perl borrowed a number of things from Lisp. And junior programmers are more productive in Python and Ruby (than Java or C++) because those languages are like Perl with training wheels.

            <rd&g>

      • Not really. I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS. This includes fancy new Java 1.5 and C# 2.0 stuff like properties, etc. Now, once you get out into real OO languages, like Smalltalk, you might find something, but its doubtful.

        Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern. It should be not
        • Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern.

          First, duplicated code != a design pattern.

          Second, what can a Lisp macro do that, say, a C macro or a function can't? (I ask merely for information, I'm not challenging you.)
          • A Lisp macro is absolutely nothing like a C macro. They do completely different things, so you can't compare them.
          • A Lisp macro is a function that is applied at compile time, not run time, so in this sense it is not like a C function.

            A Lisp macro performs an arbitrary rewrite of a Lisp expression into another Lisp expression. Because Lisp programs are expressed as Lisp data (i.e., lists), and because the full power of Lisp is available to implement this transformation, it is much more powerful than a C macro.

            The upshot of this is that macros can be used to extend the control structure of Lisp itself. (Think templates on
          • by be-fan (61476) on Saturday July 30, 2005 @11:39PM (#13205870)
            You're right, design patterns aren't duplicated code. They're duplicated patterns of code. Nearly all languages have a tool for handling duplicated code (functions), but few have tools to handle duplicated patterns of code. Lisp macros, however, do allow you to codify patterns in code.

            Lisp macros and C macros share only a name. The C preprocessor is just a simple text-substitution mechanism. In comparison, Lisp macros are functions that take source code as input, and return source code as output. They have all the generality of regular functions, except the compiler invokes them at compile-time to expand calls.

            The simplest examples of Lisp macros are defining new control structures. For example, Lisp has no direct equivalent of Python's "for elt in container" syntax. However, it's easy to write a macro that takes the statement (for (x in list) ...)" and expands it to an iteration using Lisp's native 'do' loop. Now, that's just scratching the surface of macros. Since macros are just functions, you can do anything with them, including writing a language on top of Lisp. This might seem like a bit of a strange idea, but domain-specific languages are hardly a new concept (ie: SQL), and its easier to build them on top of a mature platform instead of writing your own compiler.

            With regards to macros and patterns, an easy way to think about things is to realize that functions are useful when you need to apply the same code to different data, while macros are useful when you need to apply the same structure to different code. The classical idea is that you can't package up design patterns into a library. That's because few languages have macros (ie: functions that operate on source code). When you have such a feature, packaging up design patterns becomes easy. Just codify the invariant parts into the macro, and put the parts of the code that change as parameters to the macro. If you've read Alexanderescu's book "Modern C++ Design", you'll see that this is precisely what he does with C++ templates (which are a limited and kludgy form of macros). This is big news in the C++ world, for the simple reason that it makes code less tedious to write and less error prone.
        • I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS.

          My guess is that you meant "a feature of the Java and C++ class systems".
          I can, off the top of my head, think of three things that you can do with C++ that you can't do with CLOS, or even CL (except through external libraries):

          • Point to and dereference absolute memory locations (needed for device drivers, etc.), or use pointers in general.
            (Yes, the cdr of a cons is (usually) a kind of pointer, but it can't point to an
  • by Rubel (121009) on Saturday July 30, 2005 @08:14PM (#13205076) Journal
    I've worked with a couple of folks who swore by this book, but I never really heard much from them about why. Is it about good algorithms? Or larger design issues (such as)?

    Or is it more about just giving programmers a common vocabulary with which to discuss the way they bulid software?

    Is it good reading for an amatuer programmer, or more as an advanced topic?
    • by smitty_one_each (243267) * on Saturday July 30, 2005 @08:24PM (#13205114) Homepage Journal
      It serves as a common language for designers to talk about what they're doing.
      It gives standard terminology for talking about, among other things, how you'd implement an undo function in an application.
      However, such standardization flies in the face of the need to re-invent the wheel and sell it as a shiny new technology.
    • It's all about "design patterns", ie. the sorting and naming of common design problems a programmer has to face in object-oriented programming, and how to solve them right, so the code remains as maintainable and cohesive as possible.

      For anyone doing object-oriented programming, this should be required reading IMHO. It gives you a solid base on how to solve most moderately complex problems.
    • I think it is about idioms. There are standard ways to copy, iterate, and count. These standard not only make the code more readable, but also provides time tested methods to make the code reliable. Also using these idioms when writing code speeds up the process. There was a time when I could at sketch out a solution to a moderately complex problem in a day, flesh it out in another day or two, and then spend the rest of the time debugging and clarifying.

      When we moved to OOP, new idioms were needed. W

    • It simply opened my eyes about what true OO was about. I thought I was already fairly proficient in Smalltalk, but it's after learning a few of the patterns in the book that I truly understood the need for abstract classes and methods, the proper use of inheritance (vs composition), and the constant fight against code duplication.
    • The answer to all of your questions is "yes". It's about algorithms that solve common problems or address common issues. It's also about a common set of names, so that designers are less ambiguous when they talk to each other.

      Also important is that it lets you know of the "consequences" of using a given pattern, both good and bad. If you employ the composite pattern, for example, you treat a group of objects the same as a single object, and the container will recurse through the children.

      The other th

    • It's easy to talk about control structures like for loops, functions, etc because they have names. It's easy to say things like "it's insane to have all that code in one function".

      Software architecture, which is a level more abstract than syntax and control structures, lacked such names for some time. Instead of names, you'd describe a solution or something.

      If you haven't named something, you can't talk about it effectively. You can't discuss its pros and cons with people easily. And so on.

      "Des

    • I've worked with a couple of folks who swore by this book, but I never really heard much from them about why. Is it about good algorithms? Or larger design issues (such as)?

      Design patterns are recurring algorithms in software design. Take the "Singleton" pattern, which is usually regarded as the simplest. You use a private class variable, and a public getter (and either a setter or lazy initialize on the first get). What you're trying to do is make sure there's one and only one instance of a variable on the
    • I would say that 'Design Patterns' is at least as much descriptive as prescriptive, in that they are describing what's been found in software 'in the wild' so to speak. Each pattern includes examples of where they've been found. In addition, each pattern includes a list of pros and cons.

      I generally find that I prefer to let my code dictate my patterns, rather than the other way around. When building a system which calls for a centralized menu (or command line) to invoke various procedures, it's generally
  • Well deserved (Score:4, Informative)

    by Sv-Manowar (772313) on Saturday July 30, 2005 @08:16PM (#13205085) Homepage Journal
    Its good to see these people being recognized for contributing such a useful concept to object oriented programmers, and its wholly appropriate they should recieve such an award from a group focused on exploring "implementation and efficient use" of programming languages. Although they have their critics, Design patterns have surely helped many programmers greatly in this manner, especially in languages such as java.
  • For OO fans... (Score:4, Informative)

    by William Robinson (875390) on Saturday July 30, 2005 @08:49PM (#13205187)
    This site [ootips] is one of the best.
  • Oh dear... (Score:3, Insightful)

    by groman (535485) <slashdot@carrietech.com> on Saturday July 30, 2005 @08:49PM (#13205188) Homepage
    Oh my

    The quite possibly most useless book in the history of computer science gets an award. Somehow I am not that surprised, considering that everybody hails it as the end all of object oriented design and everything.

    To be honest, modern computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.

    Well that's barely computer science, that's just OO banging. Just because it uses paradigms and object oriented terms doesn't make it anything other than advanced code banging.
    • That happened at UCB? That's terrible news. It wasn't always so, of course.

      Check out that first comment: 16 of the 23 patterns are so simple as to be invisible when you use the right tools.
    • Re:Oh dear... (Score:5, Insightful)

      by Anonymous Coward on Saturday July 30, 2005 @09:06PM (#13205248)
      Of course it isn't Computer Science, it is Software Engineering. The book helps you design software systems. Can Karnaugh maps do that?

      I find it useful with what I work on. If you don't then, maybe the book just isn't for your line of work.

      Design patterns are a tool, not a silver bullet. Get what you can out of them but don't be surprised when doesn't solve all the problems in the world.
    • Re:Oh dear... (Score:3, Insightful)

      by TheGavster (774657)
      As a computer science major, I find it depressing that I only know what half those words mean, and I learned them all in electrical engineering courses. We really need to get back to "Computer Science is highly organized math" rather than "Computer Science is objects".
      • LOL. I find it depressing that I know most of what those words mean, but I'm an aerospace major. I learned most of them in my EE courses and from hanging out on comp.lang.lisp...
    • Re:Oh dear... (Score:3, Insightful)

      by aftk2 (556992)

      Computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.

      Interesting - tha

      • Re:Oh dear... (Score:2, Insightful)

        Computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.

        Interesting - that

        • Re:Oh dear... (Score:3, Interesting)

          by Kupek (75469)
          Programming paradigm. It's the most appropriate word to describe the different families of programming styles/languages: procedural, functional, object-oriented, imperative, logic and such. It's commonly accepted; I've seen it in places ranging from textbooks to CS papers to Stroustrup's C++ book.
    • Re:Oh dear... (Score:4, Insightful)

      by cratermoon (765155) on Saturday July 30, 2005 @09:28PM (#13205323) Homepage
      People with CS degrees seem to get jobs writing software for money without knowing a thing about security, testing, defect discovery and removal, team organization, refactoring, design, technical writing, communication, estimating, abstractions and complexity management, business practices, communicating with users... well, anything needed to actually deliver working software that delivers value to the business.

      But, you know, in case that trucking company struggling with logistics needs to know about "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis", they're golden.
    • Re:Oh dear... (Score:4, Insightful)

      by SirSlud (67381) on Saturday July 30, 2005 @10:28PM (#13205558) Homepage
      Face it; software is now a commodity business. Using an automotive analogy, if you want to improve the performance or design of the internal combustion engine, go for it, but most software jobs these days only requires putting a kit together rather than having to push the envelope of science.

      Therefore, sure, Computer Science is science, but understand that its pure semantics. Its good that enrollment in CS is down, because most of the CS students during the boom were more interested in engineering (applying known scientific discoveries) than the science itself.

      The fact that employers looking for programmers ask for CS degrees is simply an indication that the industry is still fairly young. Software engineers used to come out of CS, but that trend is rightfully dwindling. Most programmers really should be trained in an engineering course, where the focus on economics and social responsibility are more pronounced.
    • Re:Oh dear... (Score:4, Insightful)

      by Anthony Liguori (820979) on Sunday July 31, 2005 @12:49AM (#13206101) Homepage
      People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are.

      You're obviously trying to come off as pompus but seriously, do you even really know what you're talking about? What's so important about Karnaugh maps? It's a silly way as solving a system of boolean alegbra equations. Only really useful for introduction digital circuit design.

      If you want to talk about boolean logic, talk about predicate calculus, modus ponus, or something that actually deals with Computer Science theory.

      I understand where you're coming from and don't fully disagree but you sound like an ass. There's always someone with a more theoritical background than you so just don't do that.

      FWIW, the GoF are important because they were the *first* to do what they did--give programmers a common vocabularily to describe complex systems.
  • An Excellent Book (Score:3, Informative)

    by under_score (65824) <mishkin-slashdot@bertei g . com> on Saturday July 30, 2005 @08:55PM (#13205207) Homepage
    It surely deserves this award. However, after 15 years doing software development, I now consider two other books even more important even thought they are not quite as information-full as the design patterns book. They are: "Agile Software Development" by Alistair Cockburn and "Software Craftsmanship" by Pete McBreen. I have a full list of books, web sites and tools that I recommend at my Software Resources [berteig.org] page.
  • Common sense for the rest of us. It was a good idiot filter back in the day...
  • by bsandersen (835481) on Saturday July 30, 2005 @09:02PM (#13205231) Homepage

    Congratulations to the GoF. Their observations of patterns of systems and behavior are well-described and well-cataloged in their book. I only wish the concepts and materials were conveyed better when taught.

    Most of the time people start with the attitude "Let's start with the Visitor pattern" or something like that. The point of the patterns movement is there are common things that are done, wouldn't it be nice if we could talk about them with common terminology and use the full richness of our experience to ensure when we see the problem again that we don't make all the same mistakes we made last time.

    I'd like to see it taught (and this can be in the programming shop, too) like this: "What are we trying to do? Where have we done something like this before? Doesn't this look like something we've done last month? Can you detect a pattern to all this?!"

    Instead, what I often see if people spouting pattern names like one would name-drop at a party--the more you drop the more important you must be. Starting with the problem to be solved, the understanding of same, and then recognizing that we've seen this before, then naming the pattern is less flashy but is more the intent of the GoF IMHO.

    • Instead, what I often see if people spouting pattern names like one would name-drop at a party

      I'm seeing this at work, and it's driving me nuts. Our new Bible is "Architectural Design Patterns". The big push right now is to move to .NET because "it's enables Reflection."
      • Can somebody please give me a link to a rundown of how reflection improves software engineering? Is it for debugging purposes? To make it easier to write safe code for dynamic classes? I understand the concept, but I still havn't see the killer app.
        • You can do a lot of useful tricks with reflection when its mixed in with code generation, for what it's worth. Ie, dynamically build a custom class on the fly, compile it on the fly, and then instantiate it on the fly.

          For example, the persistence framework we use actually generates proxy classes on the fly that handle transaction management, etc. Hooking into these things (and determining how to build them) requires some advanced reflective techniques.

          I'll put a cheap plug here, since it's awesome: www.x-te
        • Reflection is a nice pattern. But the ADP book treats it as an *architectural* pattern. As in, it defines the entire structure of your system. Consequently, the architectural team at my work is making a brand new system based on the reflection pattern.

          My coworkers aren't stupid, they've just getting a lot of positive feedback from their use of buzzwords.
        • The only place I see it being of serious value is in automated software testing. JUnit (for Java) and NUnit (for .NET) both rely on reflection to discover the unit tests in your code and execute them.

          There's also a unit test framework for C++ called CppUnit, which was intended to bring the benefit of more formal unit testing to that language. However, since C++ doesn't support reflection, you end up having to employ macros to use it. It's not self-discovering.

          Otherwise, I haven't noticed its absence

  • by bmac (51623) on Saturday July 30, 2005 @09:10PM (#13205261) Journal
    The patterns themselves are not really that
    groundbreaking, IMO; the genius of the book
    is the perspective on looking at software
    as pattern definitions and then their use
    in different ways and places in software.

    The part that every OO developer should
    ingrain in their brain is to

    Prefer composition to inheritance.

    Good Lord, people love their inheritance
    when there are very, very rare situations
    that call for it. (Composition, btw, is
    where a data structure is used as a data
    member of the class).

    What it recommends is that instead of this:

    class cElement : cParent { ... }

    use this:

    class cElement {
          cParent mParent; ...
    }


    Inheritance is so friggin abused by OO
    developers, it is ridiculous.

    So, my recommendation is to read the first
    50 pages or so, which is their general
    perspective on programming. After that,
    it's just details about the patterns they
    have encountered in their careers.

    Peace & Blessings,
    bmac
    • Unless of course, cElement is a cParent. In that case inheritance makes sense.

      Using composition for everything is just as bad as using inheritance for everything. That inheritance seems to be your pet peeve, makes me think that you use composition much more than you should. Everything has its balance, but when you go out on a limb to tell someone else that he's unbalanced, make sure that limb doesn't break.
      • Maybe what the GP meant is that there is too much inheritance without a good reason behind it. I'm reading a book on design patterns right now and they just give you this as a piece of advice, not an order: "don't overuse inheritance when you just need to create a structure." Inheritance is a good thing but in the end you still need members to keep the info and as you said it perfectly "everything has its balance."
      • by Anonymous Coward
        Unless of course, cElement is a cParent. In that case inheritance makes sense.

        A circle "is a" elipse. Should a circle class extend an elipse class, even though a circle doesn't behave as an elipse (e.g., one cannot independently alter both axis and still have a circle). Nope. "is a" is not what matters. "behaves as a" is what matters.
      • Exactly. I'm actually programming a small GUI class at the moment for a C++ OpenGL project I'm working on, and inheritance for the widgets make a lot of sense, simply because when you have the three events that I need to account for (render, mouse click and mouse move) it is extremely simple and convenient to have a base class with the three virtual functions in a linked list so the GUI class can loop through them.

        Inheritance and composition are different tools, and are used for different purposes. Sur
      • by plover (150551) *
        Even your example has a counter example.

        I just saw a presentation where the guy gave an example of a CSquare inheriting from a CRectangle. He said look at the differences: if your CRectangle has a SetSize(int height, int width) method, what do you do if the width isn't the same as the height? Perhaps you should have a SetSize(int side) method instead. But then it's still different enough that the two really aren't as related as they seem, even though a square is most certainly a rectangle.

        I agree th

        • CSquare and CRectangle should be the same type of object. There is no need to separate them into separate objects.
          • CSquare and CRectangle should be the same type of object. There is no need to separate them into separate objects.

            Sure they should be separate classes. Consider:

            // make a rectangle 100 units wide and 50 units high

            CFourSidedPolygon rectangle(100, 50);
            rectangle.setSize(200, 50); // okay, it makes sense to widen rectangles

            // now make a square 50 units wide and 50 units high

            CFourSidedPolygon square(50, 50); // okay
            square.setSize(100, 50); // whoops, our "square" is no longer a square!

            The point is

    • I agree, to an extent. But if you throw inheritance out for composition, you really need a more evolved concept of composition than is typical.

      Inheritance is never necessary. But just saying "always use object composition" doesn't make sense either, in and of itself.

      All objects should be considered as an assembly with a boundary, with multiple terminals to connect to other components. Each terminal can have its own interface type. Multiple interfaces nodes (connectable terminals) with different types is a m
    • So, my recommendation is to read the first 50 pages or so, which is their general perspective on programming. After that, it's just details about the patterns they have encountered in their careers.

      No, keep reading!. The patterns are useful, and may give you insight into a better way for solving certain common problems. But far more importantly, it gives you a common language to use with fellow software engineers. I find that in the corporation I work for, more and more people are familiar with these p

  • An observation... (Score:5, Insightful)

    by bunyip (17018) on Saturday July 30, 2005 @09:14PM (#13205279)
    "Some is good, more is better, and too much is just about right."

    - This mantra is good for money, horsepower, disk space, but not design patterns...

    When somebody starts telling me that they used 5 different patterns in their program and they're proud of it - then I know the code is crap. Most of the pattern zealots I've seen write bloated, inefficient code. Sometimes I think they scour the literature looking for some extra patterns to put in.

    That said, these patterns do exist and programmers keep reinventing them. The key is knowing when to call it a pattern and go to the trouble of formalizing it versus just writing code. Alternatively, find a language that makes most of these go away.
    • Agree 100%. In fact I think OOP in general is overused. OOP is just one of many techniques that can be used in programming. I've done my share of Java and it's a great language but most of the Java code I've seen is so heavily OOP I don't think people even realize that they can occomplish the same task with a few lines of simple C-ish looking code. In the long run I think this will actually hurt Java as a language. A perfect example is log4j. That whole package is riddled with design pattern stuff where a s
      • Indeed. It seems to me we've bred a whole generation of new programmers who are great at thinking up fancy methods to use but useless at actually solving the problem at hand so what you get is bloated code that they've chucked everything in their limited repertoir in to get it working because they can't think "low level" and create a solution on their own. They have to use other peoples algorithms/methods/patterns or they're lost.
      • A perfect example is log4j. That whole package is riddled with design pattern stuff where a simple PrintStream with a loglevel member would have been perfect for 9/10 apps.

        Well, that's as may be, but log4j has been my company's official logging framework for the last couple of years, and in that time all we've ever had to do with it is:

        1) create a static instance of a Logger in each class that needs to log stuff
        2) call the appropriate logging method to output log lines (eg logger.debug(), logger.info(), etc
    • If you're talking about relatively small programs to solve very specific problems, I'd agree with you: having to apply 5 patterns likely means you chose the wrong ones. But for a big application there are plenty of problems that may or may not benefit from different patterns.

      As a Patterns zealot, a book I'd recommend to most Pattern fanatics, as well as to any Pattern skeptic, is "Refactoring to Patterns", by Joshua Kerievsky.

      It's a pretty good book on moving towards and (gasp!) away from design patterns ba
    • by arethuza (737069)
      Here is one pattern anti pattern that can increase the complexity of a project hugely. For each class:
      • Define an interface for the class to implement
      • Create a factory class that does nothing but call the constructor on the class
      • Define an abstract factory interface
      • Have a factory factory that creates instances of the factory based on a system property or properties file

      And do this for every class in your system!

      Design patterns are a great idea but they can lead to a huge increase in complexity when peo

      • Why on earth would you do that? I appreciate that you're just providing an example of how over-use of patterns can screw code up, but if someone on my team wrote code like that then they'd be rewriting it the moment I saw it.

        As with all things, you can take pattern usage too far. Doing so is not unique to patterns, and as in other situations, is the mark of a bad programmer. Bad programmers are going to be bad whatever tools you give them.
  • by De Lemming (227104) on Saturday July 30, 2005 @09:43PM (#13205372) Homepage
    The classic Design Patterns book is great, and the GOF certainly deserves this award. Still, the book is hard to read. And in daily practice, it's not always clear when to apply which pattern (especially for the less experienced).

    I'm reading Head First Design Patterns [amazon.co.uk], published by O'Reilly, right now. It's an fun and easy to read Design Patterns course, which is difficult to put down once you started it. The authors have a great sense of humour, and use a very practice-oriented approach. They tackle day-to-day problems by starting with the obvious solution an inexperienced programmer would use. Then they point out the problems with this solution, and step by step they work to the appropriate design pattern. Patterns are examined from different viewpoints, and the authors try to answer all the questions you might have.

    I really recommend this book. In fact, I recommend the whole "Head First" series (I also own Head First EJB). These books are not usable as reference works, but they are wonderful for learning and mastering a subject.
  • by be-fan (61476) on Saturday July 30, 2005 @09:46PM (#13205384)
    Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup [norvig.com] of the issue. Paul Graham also has an interesting take [paulgraham.com] on this subject.
    • I get your point, but its as unpractical as the answer, 'roll your own' to the 'are there any good X' questions programmers constantly poll the community for.

      In a resource constrained sitution, sometimes you are forced to re-build the wheel. However, design patterns help people prevent having to re-invent it.

      The question is; do I have to figure out *how* to build it myself, or are there recipies available out there already?

      I appreciate those who work towards building smarter and better tools, but many of us
      • Undoubtedly. Design patterns are helpful in any code, they're just easier to use when the language is properly set up to handle it. Now, it's true that a lot of people can't afford to "non standard" tools. The potential for being blamed if something goes wrong is quite high indeed. However, my point was merely that mainstream languages are not ideally geared towards working with patterns. That does not mean that they'll always be that way, however. Mainstream languages are increasingly ripping entire pages
    • If you program in C++, you should take a look at "Modern C++ Design" by Andrei Alexandrescu. To quote Herb Sutter's blurb off the back cover, "Fundamentally, it demonstrates 'generic patterns' or 'pattern templates' as a powerful new way of creating extensible designs in C++ -- a new way to combine templates and patterns that you may never have dreamt was possible, but is." Ultimately, he gives the reader pre-packaged generic implementations of several of the more common design patterns.

      Alexandrescu's pre
  • When I was in college, an architecture student friend of mine suggested that I read two books by a guy named Christopher Alexander: A Pattern Language (1977) and Timeless Way of Building (1979).

    I'm fairly confident the concept of design patterns truly originated with these two books. The concept from architecture was then applied to software.

    The fundamental idea being that there are certain components of architecture that "just work" and "feel right". They may solve very complex problems in elegant a

  • by javabandit (464204) on Saturday July 30, 2005 @11:23PM (#13205799)
    Seriously. I think some patterns are fine for some things, but as a previous poster has stated, more ugly-as-shit code has been written using design patterns than not.

    I know that in the OO languages world, this book is hailed by many as the holy book, but to me, there really is only one... "Code Complete".

    The one book teaches the fundamentals of good programming *in any language* better than any programming book ever written.

    Case in point, I don't think any shit code has been written as a result of applying the techniques and best practices in "Code Complete". I certainly can't say the same about "Design Patterns".
  • That book needed more examples.

    Granted, I read it recovering from surgery with anesthesia in my system, but I found it to be prohibitively dense material for concepts that don't warrant that density.

    The contribution to programming from those concepts will be fully realized when they are expressed in a form easily digestible by busy programmers who have to do a lot in the real world.
  • With all the hype over design patterns (usually by OO zealots who couldn't code in any other paradigm if their lives depended on it) you'd think no one had managed to write complex systems before they came along. In fact it seems to me that since the false prophet known as OO with all its attendant accolytes came along (design patterns being one of them) programming has actually got harder, less efficient and far more costly.

    IMO its time to ditch all this high level buzzword trash coding methodology and go

Little known fact about Middle Earth: The Hobbits had a very sophisticated computer network! It was a Tolkien Ring...

Working...