How important are Design Patterns really?
I think the earlier generation of programmers didn't use Design Patterns that much (people who graduated in the 80s and before mid 90s). Do the recent graduate know it in general and use it a lot more?
If you are interested, I also made a survery and you can view it here:
http://www.surveymonkey.com/s.aspx?sm=kJOdGX0RPx5FGrfPVm_2bmIw_3d_3d
Update: Here are the initial survey results:
The single biggest benefit of design patterns in my opinion is that it gives developers a common vocabulary to talk about software solutions.
If I say, "We should implement this using the singleton pattern", we have a common point of reference to begin discussing whether or not that is a good idea without me having to actually implement the solution first so you know what I mean.
Add in readability and maintainability that comes with familiar solutions to common problems, instead of every developer trying to solve the problem in their own way over an over again.
Pretty important. Software can be made without them, but it's certainly a lot harder.
They are not absolutely needed, but the good definitely outweighs the bad.
The good:
The bad:
Important isn't the word that I would use. I would use the word "helpful". Giving developers a common language to describe frequent problems/solutions is useful -- moreso in a collaborative environment.
Great question! I wast just asking myself that question about a week ago. I use them whenever I can, but I don't really find lots of opportunities to use them. I personally think that the idea of Design Patterns is great. Mechanical engineers and Electronics engineers don't design from scratch, but applying well-understood patterns that among other things allow newbies to stand on the shoulders of the knowledge laid by their predecessors. Design Patterns are a step on the right direction, but much more steps are needed.
We used design patterns in the 80's, we just didn't know they were design patterns.
I think you miss the point on what a Design Pattern is.
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.
So design patterns are just a formal language to define common ways to solve software engineering problems. I would think most people are using design patterns without knowing that they are. So these common solutions to software problems can date back a long way, they just hadn't come up with a formal language to describe what they where doing.
I think design patterns are important because they teach you the command ways to solve the problems in the areas that design patterns apply to.
Design patterns are taught in design classes for CS. They aren't essential, but really helpful if you can find analogous situations to have a solution that has been thought through.
It also allows programmers to communicate more easily. You can talk to your coworker in terms of the patterns as well. If you say here I have my Observer, then it is pretty well understood what is kind of going on.
People will naturally come up with solutions that will fit into a design pattern on their own, but the design patterns help to define terminology and standard ideas that can be helpful.
There's nothing super remarkable about the patterns, the nicest thing is that they are ideas that are canonized and defined in ways that are repeatedly useful.
I would say very
The trick with design patterns is learning where and when to use them. Then can do all sorts of things for you like:
But sometimes they can do the exact opposite of some of there benefits again its knowing how and when...
Have you ever tried to pull out a sliver with a framing hammer? You may love you framing hammer but its going to cause all sorts of problems if you try to use it that way...
I think that as you refactor you code it sometimes evolves into a particular pattern or you may have been using a pattern all along without realizing it.
Personally, I consider them vastly overhyped and of marginal value. The idea sounds great, but when you get down to it, there's really only a handful that common and useful enough to be worth remembering (and possible to remember).
I'd say their net effect is negative, due to the hideous overengineering perpetrated by people newly enamoured with the concept and trying to cram as many patterns into their code as possible. Perhaps even worse is the Maslow's hammer effect leading to bad design because instead of finding the optimal one, the developer remembered a design pattern that fits (badly).
Software Patterns are important whether you know you are using them or not... by definition.
A design pattern is simply a generalized, reusable solution to a commonly occurring problem.
You can either hack around until you re-invent the solution of every problem you encounter or you can learn the "patterns" that that programmers have been utilizing for generations. If you formalize your knowledge of most common, named patterns, you will have a common vocabulary to discuss and apply the solutions.
Enjoy,
Robert C. Cartaino
I find design patterns of marginal value. Any well-organized and designed software framework has hundreds of design patterns, and very few of them are described in the formal "pattern literature".
Before there were design patterns, there was well-designed software which had many patterns that could be re-used in many situations. For example, Kernighan and Richie's book on C contained an example of a calculator implemented using yacc and lex and a stack, symbol table, function pointer passing (i.e. basically dynamic binding) and contained a large number of patterns for the size of the book.
You can probably learn hundreds of more useful design patterns by studying e.g. Microsoft's .NET framework, Java class libraries, etc. than by reading a book on design patterns.
Really, good software has a design. And if the design is good, it can probably be re-used. Voila -- a design pattern.
I've seen too many cases of "Small Boy With A Pattern" syndrome. It usually strikes hardest just after a person has read the GoF book for the first time and instantly runs off to see how many of them they can fit into the project they're working on. (Extra points for cramming all 23 into a single project.) They end up with a system that's engineered within an inch of its life and impossible to understand or modify.
Eventually the fever breaks and they settle down enough to use them appropriately. But the damage can be great.
The cautionary tale is the "Core Java EE Patterns" book. It lists a bunch of stuff that addresses "best practices" for EJB 1.0 and 2.0 that are now considered anti-patterns. The EJB 3.0 spec does away with a lot of them. Spring is killing the rest.
Patterns have had their day in the sun, like UML. But the sun is going down on both. I don't think either one has saved the world or delivered on the hype.
While it can be useful to talk about design patterns sometimes, I tend to agree with those who consider them harmful in many situations.
The main argument I would make is that often they actually stop people from coming up with proper solutions to a specific problem. Instead of thinking about how to solve that particular problem, people try applying one design pattern after the other.
They also tend to hide language deficiencies. A lot of them are trivial in a language expressive enough. A prime example would be the Strategy pattern which is basically reinventing functional programming in a complicated fashion. Often people would be better off understanding the real programming principles instead of just talking pattern languages.
Having said that: I'd rather talk about patterns with someone than not having a common language at all. In that way they are important if there is no better option. If I can explain myself in more formal ways (e.g. algebras), then I stop caring about pattern languages. Of course some would claim I just invent my own pattern languages that way ;-)
I would say they definitely are important.
Among the typical reasons (shared vocabulary, not reinventing the wheel) they are a stepping stone to learning good software design. The majority of the design patterns out there start off by programmers with a good sense of OO principles applying what they know to solve a problem, and noticing that other people are coming up with the same solution. If you think of design patterns as a cookbook to solve the current problem you're stuck on, they're not really useful, and this is where you see the "design pattern hammer" come out and complicate designs.
If instead think of it as a window into good object oriented design you start to see how valuable they are, i.e. thinking in terms of the principles behind the design patterns instead of the specific design patterns themselves.
Start with Principles before considering Patterns, because it's the overarching design principles that inform and motivate the emergence of patterns.
For your particular problem you are best served by following principles first and foremost. If you arrive at a well-known Pattern then, congratulations, you just re-discovered a Pattern, good for you. The problem is that it could take you a long time so it depends if you want to risk inventing a few anti-patterns along the way or whether you want a short-cut to something that's already been published. Consider it though, because you'll learn more than reading someone else's description of their own work.
The down-side (as many of the very good answers here have already pointed out) is that you could be tempted to apply a published Pattern in a context where it doesn't fit or just is not warranted.
A good place to start with Design Principles is by looking at Uncle Bob Martin's SOLID principles, the nice thing about them, once they sink in, is that you feel like you already knew them (which makes you feel smart) and
Uncle Bob's book Clean Code also covers alot of the same principles with some useful examples, only not so explicitly citing the principles as the original articles, focussing more on generally organising and tidying up your Functions, Classes, etc.
commented Design Patterns are helpful if you are trying to contribute to open source projects... enough said!
