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
Design Patterns
darknessangel
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).
HTH
Simon
wz9919
nz_avatar
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.
Lee Brimelow
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.
http://www.dnrtv.com/00010/index.html
Kenneth Jonsson
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.
jarrodl
Here's my commentary on the Design Patterns phenomena that hopefully brings it down to earth a little ...
http://www.designpatternsfor.net/default.aspx pid=1
I hope you find it useful.
Rob
simon_
Fabio Alves
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.
Bj&#248;rn Erik
There are also some C# specialized design pattern books: