Design Patterns RRS feed

  • Question

  • What is the usage of common GoF design patterns in daily coding? I ask this because as a developer I'm constantly trying to improve both my code and my overall design, to create software that's easy to maintain and easy to extend--- hopefully easy to change without effecting the 'client' aspect through the use of interfaces etc---

    Is there a more straight forward application of certain design patterns? For example, does anyone sit down and actually implement a bridge pattern in their code--- you read about it a lot, but only in academic articles, you equally read of people who find them absolutely useless most of the time... I don't think I'm being a dilletante when I imagine that people want to know how to implement good practices, and not simultaeneously have to think about the theory of state automata when they're developing.

    Who is using GoF patterns on a daily basis, conciously and with apt reason, or rather, who is using these patterns as an abstraction for broader coding practices?

    Monday, March 20, 2006 6:23 AM


All replies

  • Moved to Architecture General.
    Monday, March 20, 2006 8:17 AM
  • I have not had a day go by when I have not used a design pattern from GoF in the last three years.

    As for the people who find them useless ... Alot of the patterns are very simple concepts (take the proxy pattern or abstract factory). The true value comes into play when I can tell another engineer to "create a factory that returns a proxy of the object adding <insert>". I have just explained a fairly complex architecture in a single sentence and the other engineer will if they know the patterns understand exactly what I am asking for.

    More importantly, if named as such in the code ... another engineer comes along two years from now and they understand the same patterns, they will have a very small learning curve picking up what is going on.

    I discuss these items (in particular the thinking of patterns as knowledge blocks) a bit more http://geekswithblogs.net/gyoung/articles/60934.aspx in an article I wrote for a newsletter a few months ago.

    Monday, March 20, 2006 8:55 AM
  • There is a great show where Jean Paul Boodhoo shows his test driven development techniques. This guy uses a lot of design patterns of the GoF and others as a day to day natural choice.

    Take the time to watch the first part, it's really worth it.


    Monday, March 20, 2006 10:04 AM
  • I'm using it on a daily basis and at I give a GOF Design Patterns course... I think you must know them and not only read the Gof-book but really start learning and using the patterns ,and it's not all about coding but more about designing...
    Monday, March 20, 2006 2:44 PM
  • I've heard the GoF book is a bit desne, that "Design Patterns Explained" is a little more straight forward.

    I don't mean to say useless, I mean that, when someone asks, how do I do XYZ sort of thing, and someone comes back with oh well, you need to apply the Dependency Inversion Principle there and...

    When I write code, I'm not thinking about inversion principals, or substitution principals, I may be thinking of patterns, but some of these papers seem like they were written by people who do a lot of thinking about code, but not a lot of writing it...

    Directly, I'll ask, is the GoF bridge pattern something that is worthwhile to implement in a c# dev environment? I try to make my classes (as much as I can) dependant on abstractions, but do I need to go the extra step of creating a) an abstraction, b) the implementor/interface, c) the refined abstraction, and d) the loose implementor?

    I want to decouple my classes, not have classes which have wildly different uses depending on concrete implementation.

    Thanks again for everyone's input and for moving this to the propper forum.

    Monday, March 20, 2006 5:23 PM
  • "Design Patterns Explained" is much more straight forward. I will suggest this as a reading above the GoF book.

    There are also some C# specialized design pattern books:
    Tuesday, March 21, 2006 2:12 PM
  • Here's my commentary on the Design Patterns phenomena that hopefully brings it down to earth a little ...


     I hope you find it useful.


    Tuesday, March 21, 2006 10:01 PM
  • I would strongly recommend reading as many papers and books on patterns as you can - what happens is it plants ideas, concepts, and more importantly understanding of good design into your mind.

    I do frequently refer back to specific patterns, but more often I find my own designs have a much clearer structure due to the understanding I've gained from reading around.

    Note that one of the key uses of patterns is communicating to other developers - if you say in your code comments or design docs "this is an abstract factory" then immediately most people will know what you mean - and if they don't they can quickly search for it and find a wealth of explanations on the net.

    As for specific books, I'd recommend reading Fowler's Patterns of Enterprise Application Architecture (and it's partner focused on integration).



    Wednesday, March 22, 2006 9:36 AM
  • Because there are a good deal of articles out there that tend to crib straight from the GO4 patterns, for example, with interfaces you tend to see a lot of abstract classes, whereas with the framework the reason for using an abstract class vs an interface should have some bearing on your design...

    It's especially useful to read articles such as Discover the Design Patterns You're Already Using in the .NET Framework, since it seems that many of the design pattern articles you read tend to be either written about or highly influence by roots in C++ rather than how the patterns apply to the framework overall.

    Thursday, March 23, 2006 8:32 PM
  • Bump...


    I've been a Java programmer since 92, started reading about OOP and OOD soon thereafter.  I often read about Design Patterns but didn't really get it until recently.  I now know their importance and why we should strive to use them as much as possible.  Anything less is a return to "bad habits".  I use the word bad because all studies show that only 20% of total SDLC expenditures are in development.  60% are maintainence.  Now if you're a manager of a software company, and you knew that design patterns can very effectively wipe out the huge effort it takes to retrofit and or add new function to existing code, why would you ever settle for the older "top-down" styles of the past?  It just doesn't make any sense.  Add to that the older argument of code reuse which still holds water, and you have a guarantee of success using pure OOD with Design Patterns not only for all new development, but also for code maintainence. 


    That's on top of the additional benefit of being able to isolate classes such that the proper Nunit style tests may be run at the class level.  Testing abstract classes and concrete classes amount to the new way of functionally testing code.  Earlier in the cycle you now have reusable code that's already been fully tested and ready for integration into the next phase.  Holy cow!  It's a fool proof practice isn't it?  Design to Object Oriented Goals using Design Patterns as much as Possible, Test early and often covering each class' boundary levels and the project will succeed on its own.  Of course bad design is always possible but QA efforts should ferret that out. 




    Friday, September 5, 2008 6:02 PM
  • Friday, September 12, 2008 1:18 AM