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.)
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.
Hello KFarmer,
I don’t know if that would be valuable or not. Some folks have tried. I think that DSLs and Software Factories may provide some answers there.
I’m looking not at just GoF patterns in code, but at literacy among developers in general. Not just 23 patterns in one book, but ~100 total patterns, forming a starting point… a minimum bar… that all of us can know and must know to communicate with one another.
No doctor speaks with another doctor about the ‘shin bone’ or ‘that long bone in the lower leg.’
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.
Found some time to blog. Smart Client/UI Architecture V2 of the User Interface Process Application Block
Hello UC,
Your effort, while certainly valuable, has already been done by multiple voices in various books. I agree that the attempt to create a "core language" would have to create a de-facto synthesis of these voices, I am unconvinced that it needs to occur in a formal manner or as a prerequisite. I think that the list of 100-or-so patterns can be released at the same time as a description of the underlying principles that leads us to believe that these patterns are worth knowing.
That said, unlike government, if we are to see an improvement in the science of software generation, we need to build a basis for common understanding based on some terms that we all share.
What is the common principle behind giving common names to the bones of the body or the metabolic reactions to medication? So that physicians can speak effectively to one another and avoid mistakes in patient care. We have the same end goal.
This is science.
Hi Nick,
How about extending this?
http://c2.com/cgi/wiki?PatternIndex
Must be at least 100 here…
[Fair warning: I’m married to a physician]
Nick,
Your analogy to medicine is all wrong. You are confusing jargon (in a value-neutral sense) with grammar. Specialized vocabularies (jargons) are important for communication in particular fields, but we (software types) already have a specialized vocabulary. As I understand your argument, you think we need a different (or expanded) jargon based on a new grammar (new rules for communicating information about the systems we create).
I disagree with the premise of your assertion that there are ~100 TOP patterns that every developer should know. I capitalized TOP for a reason. Underlying your premise is the assumption that there is an important body of shared knowledge that every developer needs to master. I don’t think there is any evidence that is true. The patterns that the developer of real-time missile guidance systems needs to master has very little overlap with the patterns that the typical ASP.NET developer needs to master, which has little overlap with what the developer on Microsoft’s OS team needs to master.
To get back to the physician analogy, at first glance, medical school looks like a huge data dump (cram those brains full of a seemingly endless supply of facts), but in reality, medical school is just as much about teaching the physician-in-training how to think and learn as it is about what they need to know.
Rather than concentrating on what patterns every developer needs to know, your time would be better spent on figuring out how to train developers to recognize when they should be looking for a pattern and how to find the one that fits. That means what we really ought to be doing is defining areas of specialization based on shared patterns.
Personally, I don’t think pattern literacy is anywhere near high enough to for a top 100 list.
For example, last summer, I worked in a shop that couldn’t spell "dependancy injection" and yet had tons of their own propretary patterns (don’t get me started).
The thing is that in language, you usually have to be able to point at something and have everyone agree that, "yep, that’s a chair" it may be a lazyboy, or a rocking chair, but everyone still agrees that the thing being pointed at is indeed a chair.
I think if you could get together a "patterns aliance" group together, and if the members of that group could all agree on the 7 – 12 patterns that they just could not live with out, that you would then have a foundation, or a seed to start with.
I say start small and market the hell out of that tiny collection.
When Fred from Atlanta, can say "Pattern Foo" and Barney from Detroit can sketch EXACTLY the "Pattern Foo" that Fred was envisioning, that might have something that could be called a "language".
100 patterns that every developer should know…
That’s a really tough one. At first glance, a few immediately pop into mind, but when you give it further examination you notice that patterns tend to fall into different groupings based not just on the problems they solve, but also on the level at which they solve them.
Does this imply that a SD should know, after two years, high level architectural patterns along with the nitty gritty ones?
Also, what would construe a good pattern to be incorporated? One that is encountered often? Frequently encountering the same pattern over and over though may just be a symptom of a particular failing in our software and how we design it.
http://c2.com/cgi/wiki is nice, although it is sometimes hard to find what you’re looking for though.
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/
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.
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?
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.)
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.
My experience during the Microsoft DNA push, in which Microsoft evangelists were hired to work on site to promote COM, ActiveX, COM+, and DHTML, has shown me that developers — in particular, developers with little experience — don’t just shy away from new, complex approaches to computer science problems: they *fear* them. This fear translated to camps being formed: one camp — application architecture — admiring and leveraging the new technologies to accomplish a great, next-generation application platform, and the other camp — dot-com boom developers — fearing the knowledge required just to comprehend COM and the concepts of generic programming (as C++ templates), to the point of insinuating themselves into management and demolishing the architecture team through politics.
In other words, experience has shown me that developers with little experience (e.g. two years’) are unlikely to be convinced that they want to do it, even if the technology evangelists are hired and on site.
I’ve taken a personal effort in the past couple of years to schedule classes at my workplace to teach and evangelize basic computer science concepts and component-based programming techniques to existing and budding developers among peers on the teams I’m on. The classes generated a lot of interest — outside as well as inside my teams — and I was eventually asked to teach the classes a second time, this time to a wider audience — even those outside development. I can see, from day to day, the concepts I taught being applied to new projects by the developers who attended.
And this experience is my motivation for asking about a standard method of distributing knowledge, particularly for those already in the profession.
Because I want to know if I should schedule another set of classes to teach the top 100 patterns to other developers. After I learn all 100, myself, well enough to teach them, of course. 🙂
In my previous posts , I suggested that we should create a list of the top 100 patterns that every developer
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.
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.
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 "designed to abstract the control