I have been taught design patterns, I have used them at work, but...
What are your experiences in using design patterns in your organization?
As soon as I started using and being able to identify design patterns, it improved communication on a project significantly and also made it easier for me (and I'm guessing everyone else) to look at a section and see what is going on.
A lot of it depends on where you are implementing them. If you are doing them just for the sake of using them, chances are that they bring unneeded complexity to a solution. The key is finding the right balance of when to use them and when not to use them.
For example, we have one application that is very over-engineered where you can't turn around without running into a mediator pattern. In essence, the mediator in this case used a mirrored interface of the Richtext component, and was used to "simplify" data translation from the UI to the adapter that would stick it into the database. It worked well enough until someone (me) got the task of replacing the control with a third party control. Since the interface was not aligned, there was dozens upon dozens of places that the mapping needed to be changed. In this case, passing a the control into a method that did all the work would have been just as effective and less tightly coupled.
All programmers use design patterns, by definition (a design pattern is a pattern of things that programmers tend to do). The benefit of formalizing them is that it gives you a shortcut when talking about the code flow, and using standard names lets others get a sense of what you expect your classes to be doing without reading through the code in detail.
Treating them as magic incantations is what leads people into trouble ("all my problems will be solved with a Polymorphic Adapter!").
I believe it is a little over-hyped and misunderstood.
Design patterns were supposed to be a tool you could apply to solve tough design problems.
But certain schools would tell you to apply design patterns first-hand where the problem might not even exists yet for SOC or maybe DRY-ness adding unnecessary complexity to the problem instead of solving it.
We are often poor estimators of ourselves.
A carpenter wouldn't sand his craft "just because", he sanded it so it'd fit (and finish).
If you are not using them naturally without such negative thoughts, then I think you are not using it right.
No, there are likely many others out there with similar feelings.
What if you didn't use the pattern? Have you done this and seen what resulted? Really, if you don't do this then it may be that your view of them is very different from others.
Think about a person who has never broken a bone, torn a tendon or damaged a muscle in their life compared to an athlete that has had this happen dozens of times over the decades of training and playing sports. Do either person have an objective view of the pain in a typical physical injury? Not really as for one this has happened dozens of times before and isn't likely to be that special while the other person hasn't experienced any of it and doesn't know what that would feel like.
I've previously ruminated about this here in my blog, and several commenters had answered correctly too, so I'll just underline some concepts: A pattern is a recognized recurrent solution for a recurrent problem, observed in the wild. Normally, good patterns tend to be documented, but there are also bad patterns too (see Anti-Pattern). This said, a pattern IS NOT a basic building block!
The main problem with appreciating something as patterns is that one needs to have experience in the field, so that it can have the "Hmmmm, I've seen this!" reaction.
So why do we teach them? Well, my students do not normally grasp a pattern until they proudly come up with a self-crafted (though perhaps flawed) solution, and I say something like: "Why don't you just use a Strategy there?". So there is value in teaching them, but, ultimately, they'll only be appreciated by those who've talked the talk and walked the walk.
some design patterns are common and trivial, and thus do not really elevate the communication process - because they're not worth talking about.
others are complex and non-trivial and uncommon, and thus do not really elevate the communication process - because they don't affect enough of the code to matter.
perhaps the problem lies in the expectation: why would the use of design patterns - which are arguably a minor portion of any application's codebase - be expected to improve communication?
this would be like expecting the use of, say, foreach loops to improve developer communication. It's a tool, not a dialect. ;-)
As always, "it depends."
I make heavy use of the Facade and Bridge patterns, especially in communicating ideas to non-programmers. I use the Singleton/Borg pattern on occasion.
Mostly, though, I don't use a lot of patterns because the work I do at the moment tends not to require them, and the languages I use (at least how I use them) don't lend themselves to that sort of programming.