What are the top 100 patterns that every developer must know?

It has been 10 years since the seminal publication of the Gang-of-Four Design Patterns book.  Since then, at least a dozen major works have followed, each with its own viewpoint, its own set of repeatable problems.  Some took on Architecture, others Real Time Systems, and so on. 

Now, the goal of the Patterns work was not to create a bunch of noise that dies down.  It was to change the way we communicate with one another.  The language that we use. The forces that we consider.  The patterns themselves, even when not fully understood, can lead us to what Christopher Alexander called "the quality."  A design that is beautiful, elegant, balanced, and completely in context with its environment.

We have the words.  We have too many of them.  Now, it's time to make the language.

Will you help me? I'd like to start to create a consensus list.  I'd like to answer the question: what are the top 100 patterns and idioms that every developer should learn by the end of their second year of professional practice? 

Is 100 the right number?  Only by attempting to create the language will we actually know what the right number is.  Scientists in other disciplines have settled on common terms for their common field.

It is our turn.

If someone has a suggestion for the best Wiki site to do this on, please reply. 

(Please note: I followed this post with a follow-up post that attempts to answer some of the questions from the responses below.  See here.)

Comments

• Anonymous
  February 11, 2007
  I'm often hoped for some sort of pattern-based programming language.  Constructs such as Singleton<T>, Adapter<T, U>, Channel<T>, and the like.  I figure a well-designed one would be able to compose easily, possibly even visually.

• Anonymous
  February 11, 2007
  The comment has been removed

• Anonymous
  February 12, 2007
  I agree that it is important to have a unified language for describing patterns of architecture. However, the idea that there are 100 "top patterns" bothers me. First, the concept of patterns arose out of a recognition of patterns in architecture, not out of a creation of them. We humans recognize patterns in all kinds of things. However, I think that what is more important than naming patterns is to understand the underlying mathematical principles that create them. The number of possible geometric patterns, for example, is virtually infinite. However, the classification of the mathematics that creates these patterns is much less complex, and more useful. In the science of building architecture, similar ideas have revealed themselves, and the solution has inevitably involved a recognition of the underlying mathematics of the architecture itself. The principles of physics are relatively simple, for example. The greatest problems lie in accounting for the human element in the equation. Like building architecture, software architecture involves a human interface, which must take into account the complexity of the human psyche. However, complexity seems to always evolve out of simplicity. Complex things are made up of lots of simple things. And I believe that the complexity of the human psyche is also derived from an underlying simplicity. So, what I'm trying to get at here is that we humans have a tendancy to recognize and identify patterns, but often overlook the underlying principles from which they are derived, perhaps out of sheer laziness, or improper focus. When this happens, we end up in a situation where the language we use to communicate about these things becomes increasingly complex, and less reliable. Like our American government, we can get so bogged down in an examination of the permutations of complex ideas that we are in danger of losing sight of the basic principles from which they originated. It is when this happens that the process breaks down. In other words, perhaps the idea that there are 100 patterns with which we should all be familiar is a symptom of this phenomenon in software architecture. It might be better to identify the principles from which these patterns are derived, and develop a common language to describe those principles. I am not saying that the patterns (and the names we give them) are useless. They have been identified out of a recognition of their usefulness. What I am saying is that before we try to identify the "top 100 patterns," the job will be easier, and less likely to grow out of control, if we first identify their foundations.

• Anonymous
  February 12, 2007
  Found some time to blog. Smart Client/UI Architecture V2 of the User Interface Process Application Block

• Anonymous
  February 12, 2007
  The comment has been removed

• Anonymous
  February 12, 2007
  Hi Nick, How about extending this? http://c2.com/cgi/wiki?PatternIndex Must be at least 100 here...

• Anonymous
  February 12, 2007
  The comment has been removed

• Anonymous
  February 12, 2007
  The comment has been removed

• Anonymous
  February 12, 2007
  The comment has been removed

• Anonymous
  February 12, 2007
  I agree with JohnCJ. The common patterns in a particular domain maybe different from those in others (hence the drive behind creating DSLs). There might only be 10 - 20 truly common patterns, and even those may take different forms depending on their context. I think a better approach would be to teach developers what patterns not to use (anti-patterns)! The patterns themselves are not as important as the underlying principles (quoted for any readers not familiar with them):

1. Encapsulate what varies.
2. Program to an interface, rather than an implementation.
3. Favour composition over inheritence.
4. A Class should have only one reason to change (SRP).
5. Sub-types MUST be substitutable for their base (LSP).
6. Classes should be open for extension, but closed for modification (OCP). You are no doubt aware of the portland pattern repository: http://c2.com/ppr/

• Anonymous
  February 12, 2007
  I don't know about the top 100, but i've cataloged 2,000 such design patterns at my site noted above. Celso Gonzalez and I are in the process of trying to make some sense of this set. One key thing I'd observe: your chose of the top x is going to vary widely depending on your domain. If I'm building a typical Web-centric enterprise system, my system's architecture will be very very different from, say, a time-driven hard real time, safety critical system.

• Anonymous
  February 13, 2007
  As an aside, I believe the GoF book was due to be revised. Not sure if this is still happening with the demise of John Vlissides?

• Anonymous
  February 14, 2007
  If we are devising a standard of knowledge, then there must necessarily be a standard method for acquiring that knowledge. (Typically, this is through an accredited academic degree.) So, if we are to mandate the top 100 patterns and idioms that every developer should learn by the end of their second year of professional practice, I would, personally, be just as interested in what the standard method for acquiring this knowledge will be. Will a board be formed to develop and administer a standardized exam that all current professionals will be required to pass as standards are updated by the board? Or, will accreditation requirements at undergraduate universities be upgraded for new students, while existing students and alumni will be grandfathered in? How will new hires be fairly and uniformly tested across organizations against a standard body of knowledge? Or, will developers be required to be licensed, and part of the licensing process is a standardized exam? (I've intentionally left out the concept of an honor system whereby all developers with two years of experience are expected to be motivated by a love of knowledge and will spend personal time and money on the pursuit of published academic knowledge.)

• Anonymous
  February 14, 2007
  Hello Don, > I would, personally, be just as interested in what the standard method for acquiring this knowledge will be.< Good question.  The fact that we have not decided how the professional is supposed to acquire this knowledge does not reduce the value of generating it.  It is a question worth pursuing, of course. You have, interestingly, left out marketing as one of your motivating factors, yet I would certainly put marketing as one of the prime movers of people in any profession, ours included.  Have you so little understanding of what it takes to drive behavior as to leave out the most pure answer of all: convince the developer that he already wants to do it?  (why do you buy toothpaste?  It isn't because your dentist orders you to, I'll tell you that). Alas, I work in a culture that both recognizes the value of marketing and understands its limitations.   I won't go into details.  That would make me sound cynical.  Trust me.  It can be done.

• Anonymous
  February 15, 2007
  The comment has been removed

• Anonymous
  February 19, 2007
  In my previous posts , I suggested that we should create a list of the top 100 patterns that every developer

• Anonymous
  February 26, 2007
  I would say that yes its a good idea to come up with a good exhaustive list of top n design patterns. Better yet, lets categorize them by vertical market/industry rather than by separating them by structural , behavioral or other abstracted forms. Most importantly, I think we should try to make that information very simple and "must must" explain each design pattern by real world examples and issues and not some theoretical concepts. Lots of books and articles scratch the surface but only complicate the subject. What I think would be a good is to take a one real world problem domain in each vertical and split that one problem domain into design modules across all its tiers (UI,Business, data access and so on) and apply relevant design patterns across all the tiers of that one problem domain with the overall goal being that when stitched together it would serve as end to end solution. That would add lots of value to the readers. my 2 cents.

• Anonymous
  February 26, 2007
  Hello Praveen I wonder about the notion of seperating design patterns by vertical industries.  Verticals are a mechanism for organizing business.  In essence, you are aligning solutions by the problems they solve.   The problem with this thinking is that patterns are not solutions to business problems.  They are recognized methods for seperating the common elements from the varying elements in a shared problem space as a reaction to specific forces.  They are abstractions.  That is why it is so important to learn more than you have ever used before: to truly stretch your mind and heart, and that is why grouping them by industry is odd, because the forces the lead to the generation of a pattern will normally exist in multiple industries, and have more to do with system quality attributes than industries. In fact, I'd say that a better way to organize the patterns in the top 100 is by the system quality attributes that they support: performance, scalability, maintainability / configurability, and many more.  In that sense, you get a better sense of the tradeoffs you are making and the patterns that align with the tradeoffs you want to make.

• Anonymous
  December 03, 2008
  Found some time to blog. Smart Client/UI Architecture V2 of the User Interface Process Application Block (UIPAB) is out from PAG [via Mike ]. I must confess to being confused on how this is different than CAB as &quot;designed to abstract the control