This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

voted to close as not constructive - this is basically a poll. Unless someone has an empirical study to cite, the answers will all be guesses or favorites (or non-favorites) and the votes will reflect personal sentiments. The end result will be a list of design patterns with no depth. Hence, not constructive.
–
Steven A. LoweMar 3 '11 at 21:17

@Arturo - That's one possible reason. Others: 1) Small project started by inexperienced programmer that is unexpectedly successful, and then grows beyond it's original purpose. 2) The tendency of inexperienced programmers being assigned to maintenance, who then don't have guidance or understanding of the original architecture, so they just hack stuff in, and it gets worse as system ages. 3) The team uses the wrong technology, or a new technology they are unfamiliar with and use it poorly on a new project, and it craters before the deadline :)
–
JaySep 24 '10 at 16:06

1

LOL - if I could add more points to you, I would. Excellent (and sad) observation.
–
luis.espinalFeb 24 '11 at 15:18

I was going to say that the OP's question is rather silly (I still believe it is). However, your answer is pretty much right IMO. If there is one pattern (and its variations) that is pretty much used consistently, it is this one. +1 for your good answer.
–
luis.espinalFeb 24 '11 at 15:15

If you're talking about Gang-of-Four design patterns I would have to say Singleton. This is a really sad state of affairs - almost as if programmers hear about the magic of design patterns and then simply stop after the first one.

If you're talking about architectural-style patterns (in other words, design patterns which span multiple classes or layers) I would have to say MVC. A few other popular ones are the repository pattern and service-locator.

I am surprised no one has mentioned the Factory pattern, in my experience that is one of the most used (and also most abused) of the patterns out there. If not first, probably the singleton should be first, I would have thought this would be a close second.

Along with my previous answer, I'm going to add a new one I ran into today from my beast of an inherited project:

Copy/Paste

While debugging I ran into a piece of code calling 2 similarly named functions:

if(x)
Func1
else
Func2

Func1 and Func2 had the same parameters. I pulled them out and diffed, and they are 100% the same except for Func1 calls Func3 and Func2 calls Func4. I pulled those out and diffed them. 100% the same, except for 1 line. So a previous programmer decided to copy and paste two 50-line-nested functions, instead of adding a flag parameter, to 2 private functions used in exactly 1 place. It makes me want to cry.

Talking about Gang-of-Four design patterns, I can't think of a program that does not use the Observer pattern. Also, as Jaco mentioned, Singleton is highly used too, unfortunately it has become a hammer (any programmer uses it even if it's not completely needed).

Funny, but I've never had the need to use a Singleton. If I need someplace to hold global state, I put it in a configuration file and use a normal class to access it.
–
Robert HarveySep 24 '10 at 15:01

I'm surprised no one has said "Builder" yet. Or "Adapter". They're probably not as exotic as some of the other ones mentioned, but I use them all the time. Factory and Abstract Factory are very common as well (but they're already taken).

At the software design level, I would argue that Composite, Strategy and Template (and to a lesser extend, Factory) are the most widely usage. For the last decade or so we have seen a preference for composition over inheritance when building our systems using a OO design. As a result, combination of the patterns just mentioned play a much more important role than all others IMO.

Architecturally, I'd argue for MVC on the enterprise, and patterns based on state machines on the embedded side of things.