Possible Duplicate:
Are design patterns really essential nowadays?
I recently read a book on design patterns. A few of them seem very usefull in specific situations. Im not sure how much use they will be in everyday coding though. How often do you use design patterns in your everyday work? Should I be trying to find situations to apply them?
I kind of use them in reverse. Mostly for documenting purposes. If I say that some class is a "singleton configuration holder", I can safely assume that most people will know what the class does/is.
I don't really try to fit the design patterns into my code. The only exception is the design phase, where it is mostly a discussion starter, ie. should this class be a factory (why yes?, or why not?).
Design patterns are great, for the specific situations that need them. You should never need to try find a situation to apply them, as you'll often know when you need to apply them anyway by looking at a problem and thinking "This really fits with the singleton design pattern, maybe I should solve it that way".
They're not a one size fits all hat, but they are incredibly useful. As long as you understand what they do and why they're useful, and why they occasionally aren't, you'll see the situations where you can use them.
There's a psychological phenomenon called "med-student's disease", in which a person who studies an ailment becomes convinced that he himself suffers from it. Apparently, it's quite common.
Design patterns have a similar effect on programmers. He learns about, say, the façade pattern and suddenly, every object needs a façade. He's putting façades on top of his façades. Madness.
I myself have been studying combinators for the last few weeks and -- by complete coincidence -- have been finding uses for them left and right.
You actually seem to have the opposite problem. You are reading about patterns and thinking, "When the hell will I ever use these?"
I respectfully submit that, well, that maybe it's you. Perhaps it's because you don't understand the patterns well enough, or because your programming experience has not been broad enough for you to have seen the patterns. Something.
The notion of design patterns, and the patterns themselves, are popular with programmers because we actually have run into them, over and over. The original patterns -- like functions and for-loops -- showed up in assembly language and then were built into higher-level languages. The next group (mostly the GoF patterns) haven't made it into languages yet but they are common use and their names are in the common vocabulary of programmers. On the horizon are concepts that have been floating around academia for a decade or two (monads, combinators) and are just starting to find acceptances in the commercial world.
My point, and I do have one, is that if it weren't for many, many programmers using design patterns every day, they wouldn't be design patterns; they'd just be some code that some guy wrote and then forgot about.
Design patterns put a name on specific code constructs that existed before the design pattern book was published.
You have to see it as a construction guide that helps people work together. And that help beginners to see what works for specific situations and what they can do.
Then, it's not because you used a pattern that your choice was correct and your design sound.
Generally if you design a system, you decide upon a couple locations where given "major" design patterns fit. Even a pretty big application will have 2-5 of them used at most. A medium one will utilize one or two. Smaller ones will often do away without them altogether, or stick to one old established standard like MVC or Observer.
Then there are "minor" design patterns. Like "single-use block", or "taint flag" or "timeout counter" or the likes, which are used all the time. I'd say roughly half of the functions in any program contain at least one of these minor design patterns.
