Did the Gang of Four thoroughly explore "Pattern Space"?

Question

Ever since I first learned about the Gang of Four (GoF) design patterns, at least 10 years ago, I am having the impression that these 23 patterns should be only a small sample of something much larger which I like to call the Pattern Space. This hypothetical Pattern Space consists of all recommendable solutions (known or unknown) for common object oriented software design problems.

So I expected the number of known and documented design patterns to grow significantly.

It did not happen. More than 20 years after the GoF book came out, only 12 additional patterns are listed in the Wikipedia article, most of which are much less popular than the original ones. (I did not include the concurrency patterns here because they cover a specific topic.)

What are the reasons?

• Is the GoF set of patterns actually more comprehensive than I think?

• Did the interest in finding new patterns drop, maybe because they have been found to not be all that useful in software design?

• Something else?

Answer 1

When the Book came out, a lot of people thought that way, and there were many efforts to create "pattern libraries" or even "pattern communities." You can still find some of them:

• "Pattern Community", WikiWikiWeb
• "The Design Patterns Study Group of New York City", Industrial Logic
• "Patterns Catalog", The Hillside Group

But then...

Did the interest in finding new patterns drop, maybe because they are not really that useful in software design?

This, very much. The point of design patterns is improve communication between developers, but if you try to add more patterns you quickly get to the point where people can't remember them, or misremember them, or disagree on what exactly they should look like, and communication is not, in fact, improved. That already happens a lot with the GoF patterns.

Personally, I'd go even further: Software design, especially good software design, is far too varied to be meaningfully captured in patterns, especially in the small number of patterns people can actually remember – and they’re far too abstract for people to really remember more than a handful. So they’re not helping much.

And far too many people become enamoured with the concept and try to apply patterns everywhere – usually, in the resulting code you can’t find the actual design between all the (completely meaningless) Singletons and Abstract Factories.

Answer 2

I am having the impression that these 23 patterns should be only a small sample of something much larger which I like to call the Pattern Space.

This is the dreadful assumption that is propagated by neophyte programmers everywhere, programmers who think that they can write a program merely by stitching together software patterns. It doesn't work that way. If there is such a "pattern space," you can assume that its size is effectively infinite.

Design patterns (in the GoF sense) have but one purpose: to compensate for deficiencies in the programming language you are using.

Design patterns are neither universal nor comprehensive. If you change to a different, more expressive programming language, most of the patterns in the GoF book become both unnecessary and undesirable.

Answer 3

I think there are three factors that come into play here.

Lack of Critical Mass

First, a pattern is basically little more than giving a name to some code that implements a particular "chunk" of functionality. The only way that name provides much real value is if you can depend on everybody knowing what the name means so just by using the name, they immediately understand quite a lot about the code.

Patterns never established the critical mass they needed to accomplish that though. Rather the opposite, AAMOF. In the 20 (or so) years since the GoF book came out, I'm pretty sure I haven't seen as many as a dozen conversations in which everybody involved really knew enough design patterns for their use to improve communication.

To put it slightly more quaintly: design patterns failed specifically because they failed.

Too Many Patterns

I think the second major factor is that, if anything, they initially named too many patterns. In a fair number of cases, the differences between patterns are sufficiently subtle that it's next to impossible to say with real certainty whether a particular class fits one pattern or another (or maybe both--or perhaps neither).

The intent was that you'd be able to talk about code at a higher level. You'd be able to label a fairly large chunk of code as the implementation of a particular pattern. Simply by using that pre-defined name, everybody listening would usually know as much as they cared about that code, so you could move onto the next thing.

The reality tends to be nearly the opposite. Let's say you're in a meeting and tell them that this particular class is an Facade. Half the people in the meeting either never knew or have long since forgotten exactly what that means. One of them asks you to remind him of the exact difference(s) between a Facade and, say, a Proxy. Oh, and the couple of people who really do know patterns spend the rest of the meeting debating whether this should really be considered a Facade or "just" an Adapter (with that one guy still insisting that it seems like a Proxy to him).

Given that your intent was really just to say: "this code isn't very interesting; let's move on", trying to use the name of a pattern only added distraction, not value.

Lack of Interest

Most design patterns don't really deal with the interesting parts of code. They deal with things like: "how do I create these objects?", and "how do I get this object to talk to that one?" Memorizing pattern names for these (as well as the aforementioned arguments over details and such) is simply putting a lot of energy into things most programmers just don't care very much about.

To put it slightly differently: patterns deal with the things that are the same between lots of programs--but what really makes a program interesting is how it's different from other programs.

Summary

Design patterns failed because:

1. They failed to achieve critical mass.
2. Differentiation between patterns was insufficient to guarantee clarity.
3. They mostly dealt with parts of code almost nobody really cared about anyway.

Answer 4

Patterns are missing abstractions, simple patterns are abstracted, complex patterns are not recognized, so patterns are not useful (except a few high level ones).

I think Paul Graham said it best:

When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

When you recognize a pattern in your code, it means something repeats itself and you should use a better abstraction. If you don't have a better abstraction, you use the pattern as a workaround. Because newer programming languages provide better abstractions, patterns become much less useful.
Also simple patterns are often easily abstracted and complex patterns rarely recognized.
When a pattern becomes replaced by an abstraction, it does not mean that the concept behind the pattern disappears, but that the concept can be written explicitly instead of indirect and that it is no longer special compared to other code and it becomes no longer recognizable as a pattern.

Answer 5

While I mostly agree with what others answered here, I personally think that a main reason for a not growing number of patterns is that patterns loose their meaning when there are countless ones. The nice thing with these few patterns is, that they cover a lot of problem domains in a standard way. If you'd focus on an endless pattern domain you'd end up with no pattern at all. It's a bit like "how long is the coast line of an island?". If you measure on a map you come with a decent number. But if you try to get more exact and got to a finer resolution, you will find that the length increases more and more to infinity (or uncertainty; how would you measure the exact border with tides and on atomic level?).

Answer 6

Something that none of the other answers mention that is also relevant:

The rise of dynamically-typed languages.

When the book first came out there was serious discussion that Java was just too slow to do real work in. Now Java is frequently used over more expressive languages because of its speed. Maybe Ruby, Python, JavaScript, et al are still too slow for some important classes of applications, but by-and-large they're fast enough for most purposes. And JavaScript at least is actually getting faster despite having more features packed in every release.

The original GoF book had the patterns in both smalltalk and c++, and if memory serves the patterns were always shorter in smalltalk and sometimes significantly so. Some of the features of the classic design patterns are really ways to add dynamic features to a statically typed system (like the already discussed AbstractFactory, in which you instantiate the correct class based on runtime data). Others are so much shorter in dynamic languages that they simply meld into idiomatic use of the language itself.

Answer 7

It did happen. Dozens if not hundreds of books were published in what looked like an attempt to reduce the whole of computer science to design patterns, as publishers and authors attempted to jump on (or create) yet another bandwagon. I have a shelf of them. Never consulted since first scanned, and yes I was a sucker, because there was little or nothing in there of any actual use or that wasn't already well known (see for example Type Object, which is nothing more than third normal form expressed over a dozen pages instead of one paragraph), and because obviously the fewer patterns the better: a point which eluded most of the practicioners. Indeed, when I posted a rebuttal of Type Object, I was instructed to recast my text as a design pattern. True story. Which also shows another deficiency of the project: no review or exclusion or rejection mechanism.

As a matter of fact the GoF didn't actually attempt to 'thoroughly explore Design Patterns'. Rather, they were engaged on a much larger project: to introduce 'pattern language' into CS, with all its bizarre notational arcana of Forces, Participants, etc., which simply failed, because it was fundamentally misconceived, as well as being pointless.

What they did accomplish, which was useful, was two things:

• publish several useful tricks such as the Visitor pattern
• provide a standard set of names which has largely stuck: Factory, Adapter, Iterator, ... If you look at CORBA, which was designed immediately beforehand, you will see the value of this: all sorts of 'foreign' names such as Interceptor, Servant, Broker, ...

Another useful concept that arose was the 'anti-pattern', e.g. 'log and throw'. The project, like many fads in CS, was derailed by its own evangelism and by being misguidedly adopted as yet another CS religion, and it went the way of most such religions: useful in parts, but certainly 'no silver bullet' ((c) Fred Brooks, 1965). Sad that we have to keep rediscovering that every few years really.

Answer 8

There were/are several books titled PLoP (Pattern Languages of Program Design) which are each an anthology of papers presented at an annual conference.

Reading the books, I found some of the patterns were interesting and new to me, some of them standards (e.g. "half object plus protocol").

So no, the GoF's collection wasn't exhaustive, and inspired/inspires people to collect/describe/discover/invent new ones.

The "only 12 additional patterns listed in the Wikipedia article" presumably aren't a complete collection either: i.e. there are others documented elsewhere, e.g. in the PLoP books and maybe elsewhere too.

Answer 9

The Gang of Four (GoF) book contains most patterns that an experienced programmer in a none functional language have in their tool belt. It is like the basic set of tools that all builders know how to use. The primary contribution of the book was to give well defined name to the patterns that were in common use by most experienced programmers at the time and hence aid communication between programmers discussing design options.

You expect that an electrician to have some tools that a normal builder does not, likewise you would expect that a WPF programmer to know the design patterns for “Dependency Properties”, or a “SQL Programmer” to know the design pattern for using triggers to create audit data.

However we don’t think of these as “Design patterns” due to them only being used with one technology.

Some more modem design pattern books are “Refactoring, Improving the Design of Existing Code (Martin Fowler)” and “Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)” Both of these books present the contents as transformations you make to your current code, rather than as “pre canned reusable design”, however they are just as much “design patterns”.

Answer 10

Here is an interview with Erich Gamma where he reflect on their selection of patterns and what they'd change today (well today as of 10 years ago, haha).

http://www.informit.com/articles/article.aspx?p=1404056

Larry: How would you refactor "Design Patterns"?

Erich: We did this exercise in 2005. Here are some notes from our session. We have found that the object-oriented design principles and most of the patterns haven't changed since then. We wanted to change the categorization, add some new members and also drop some of the patterns. Most of the discussion was about changing the categorization and in particular which patterns to drop.

When discussing which patterns to drop, we found that we still love them all. (Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.)

So here are some of the changes:

• Interpreter and Flyweight should be moved into a separate category that we referred to as "Other/Compound" since they really are different beasts than the other patterns. Factory Method would be generalized to Factory.
• The categories are: Core, Creational, Peripheral and Other. The intent here is to emphasize the important patterns and to separate them from the less frequently used ones.
• The new members are: Null Object, Type Object, Dependency Injection, and Extension Object/Interface (see "Extension Object" in Pattern Languages of Program Design 3, Addison- Wesley, 1997).
• These were the categories:
  • Core: Composite, Strategy, State, Command, Iterator, Proxy, Template Method, Facade
  • Creational: Factory, Prototype, Builder, Dependency Injection
  • Peripheral: Abstract Factory, Visitor, Decorator, Mediator, Type Object, Null Object, Extension Object
  • Other: Flyweight, Interpreter

Answer 11

The actual patterns in the book are sometimes really useful, but they are really just instances of a more powerful tool that the book gives you: a deep understanding of when and where it's better to cut monolithic code in independent parts separated and regulated by an interface.

When you learn that skill, you realize that you don't need to remember the exact details of every single pattern, as you can always cut the solution you are implementing in the way that best fits its purpose. So the idea of writing down more and more patterns seems very academic and pointless.

Answer 12

So I expected the number of known and documented design patterns to grow significantly.

It did not happen. More than 20 years after the GoF book came out, only 12 additional patterns are listed in the Wikipedia article, most of which are much less popular than the original ones. (I did not include the concurrency patterns here because they cover a specific topic.)

The GoF book and Wikipedia are hardly the only source of known design patterns. If you just search for "design patterns" in Amazon.com you get hundreds of books (try this search). I guess they only list the most well known pattern in the Wikipedia article.

So the problem is not that there are not enough documented design patterns. Rather there are so many that nobody can memorize them all and most programmers recognize only a few. The big promise of common pattern language breaks down at this point.

Answer 13

There are probably plenty of structures that haven't yet been thought of. As long as people are developing software, there will be design challenges to overcome. Some of those may well be solved using clever new patterns that others could make use of.

Programming languages have developed and progressed to abstract away the most commonly used patterns. Those patterns still exist in the design of the languages. So they may be ignored today, but that doesn't make them unimportant.

Is the knowledge of how to construct a house suddenly unimportant once we have robots that can do it for us? I would argue no, it's not. It's less relevant, sure - and probably a lot less rewarding to study, since the demand did drop sharply, and no one else is studying it.

So no, I don't believe pattern space as you call it has been exhausted. As another answer pointed out, it's likely to be infinite. But as the demand for systems design dies down, as we increase the height of our tower of abstraction and the power of our programming languages - fewer and fewer people building away on the top tiers will pay attention to the details of how the tower was built.

Answer 14

Patterns are infinite.. You can tweak each pattern or mix n match to create new ones.. Enterprise integration patterns are also well defined..so yes gof did take pain of documenting patterns using uml and created a standard for explaining them.. But for each domain patterns evolve and they also change for expressive language like python or scala..