Jaa

Top 100 patterns: how to pick the list

  • Artikkeli

In my previous posts, I suggested that we should create a list of the top 100 patterns that every developer should know.  Of course, the challenge is this: how to pick the list?  There are thousands!

Let me start with criteria and see if we can approach it logically (alas, logic is the developers greatest weapon and most bothersome weakness.)

So, the question I want to ask this group is two-fold.

  1. What are the criteria for considering a pattern as part of the set of "the most important patterns so far," and
  2. What patterns do you believe should be members of this set.

The goal here is communication.  We are building a common "base of concepts", so for the sake of this set, we want patterns that explain or demonstrate fundamental ideas, or which other patterns are composed of, so that we can communicate amonst ourselves.  Therefore, we may elect to include a pattern in the set that we don't expect to use very often, simply because it does a fine job of explaining a key concept or being useful for understanding other patterns.

Some ground rules:

  1. No patterns that describe the behavior of humans reacting to one another, collecting requirements, or performing the act of writing, deploying or maintaining software.   These patterns belong to the areas of organizational psychology and process management.  For the sake of this list: the pattern must be implementable in code.
     
  2. No algorithms, even if the algorithm has been documented as a 'pattern' in a peer-reviewed work, this list needs to differentiate between patterns that establish, demonstrate, or communicate fundamental principles, not ones that implement specific algorithms.
     
    For example, I do not believe that 'circular buffer' is a good candidate.  It is an algorithm (and a good one), and perhaps a useful pattern in its own right, but I don't believe that it is a pattern that belongs in this list.  Of course, we are going to have to have a debate on the patternity test at some point.  We may also need to decide that we will keep a seperate list of 'algorithms that every developer should know.'  (then again, I'm inclined to leave that work to Dr. Knuth).
     
  3. No business rules or best practices, even if the business rule has been documented as a 'pattern' in a peer-reviewed work.  A pattern that simply describes a 'common business rule' that applications in a particular space should implement may not be fundamentally useful for creating a basis of communication among developers.

I'm thinking the set could break down this way:

25 low level design patterns
15 mid-level application architecture patterns
20 high-level system integration patterns
10 patterns related to performance and real-time systems
10 patterns related to data management, persistence, and retrieval
10 patterns related to system components that behave in a particular manner
10 misc patterns useful for describing key concepts

Opinions?  (The weakest part of this post is the breakdown above.  I don't think I got that part right.  Your feedback would be great).

Comments

  • Anonymous
    February 19, 2007
    Make sure to include example with each pattern! If it's used in web scenerio (web app), make sure to include when to use and when not to...Just for more clarification! Can't wait to see the list of all 100 patterns...should be good knowledge base! My $0.02!

  • Anonymous
    February 19, 2007
    I agree with your assertion that one criterion is whether a pattern is one of which another pattern is composed -- patterns which other patterns are built on should definitely be "core" patterns. Based on feedback in other posts, perhaps another criterion should be whether a pattern applies across problem domains. So, a pattern specific to a real-time system is less of a "core" pattern than, say, a pattern that applies to batch-processing systems and user-interface-driven systems as well as real-time systems.