Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- Christopher Alexander
A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context. - Design Patterns Book
Some topics that categorize Design Patterns into the Gang Of Four categories:
Given that patterns could be applied to many different disciplines, I would suggest that we talk about Software Design Patterns, to differentiate from Architectural Design Patterns or other kinds. Then the question is, are there any design patterns that work across specific disciplines? I doubt it, although there may be some "meta" patterns...
Why it is easier to find an Anti Pattern than a Design Pattern or an Amelioration Pattern in this Wiki?
Maybe because it is easier to look at something one has done and say "Oh, I shouldn't have done that" than it is to look at something one has done and say "My, that was successful. What made it such a success was..." I think it's the same reason it's easier to tell somebody what not to do than what to do.
Maybe this is the same reason why there are basically much more ways to insert bugs in code than to insert correct statements :) -- Flavio Poletti
Isn't the definition or existence of a problem a preceeding step to finding a solution? So to find a successful pattern you have to have first determined some failed approaches which offer needed contrast. Also, it is intuitively persuading to think that there are more ways to fail than to succeed.
The Software Design Patterns Index may be a page you are looking for. It lists at least quite a few of the "design patterns specific to Software Engineering", as described at the Software Design Patterns page. The Index is not automated, so it may be out of date, and there you are free to update it, if you find it so.
Mark Jason Dominus has apparently prepared a 5-minute lecture in which he questions whether the people in the Software Design Patterns movement are really doing what Christopher Alexander was talking about. To the extent one can get the gist of his argument from the web version of his slides at perl.plover.com 
, what do the folks around here think of it?
Tiny Wiki, the Perl Patterns Repository, wiki.slowass.net enumerates some differences between Christopher Alexander's Design Patterns and the Gang Of Four's version. It doesn't belong in black and white, but there are differences, and apparently a need to defend what Perl Patterns Repository is doing. -- Scott Walters
This is an old, old argument in the Software patterns community. This subject has been brought up and rehashed at every single PLoP (and probably EuroPLoP) conference since the very first one. In fact, the Pattern Languages Of Programs conference was founded to try to move the community more towards Pattern Languages and away from pattern catalogs. However, that's still not been enough for some people. The consensus of the patterns community has been "we know...we're going to do our thing anyway..." -- Kyle Brown
I am yet to see a design pattern (only Software Design Patterns ;-) ) which is a major variation from the 23 patterns Gamma et al. have documented. If you have one, please provide a link here. Patterns resulting from a combination of different patterns from the Design Patterns Book need not be listed here. Moreover, patterns listed here must be general and not tied to specific environments.
The Gang Of Four book didn't invent all those Design Patterns you know. They went out and tried to document the most fundamental object oriented Design Patterns they could find over several years. I'm not sure what would be achieved by searching for Design Patterns that someone sufficiently bloody-minded couldn't claim was linked to one of the 23. Besides there's also the effect that people who've been exposed to the Design Patterns Book will tend to see new patterns in terms of their relationship to the 23. It would be like trying to discover a new colour. Someone will always be able to say "actually that's just a grey-green-blue." -- Adewale Oshineye
One can argue that many of the GoF patterns are not fundamental to OO design, but rather work around limitations in particular implementations of OO. For example, several patterns in the GoF book that work well in Java or C++ are unneeded in languages with a more powerful OO approach; especially the creational patterns, which are very much to do with getting around the problems of constructors in C++, Java, C#, etc., not working just like any other method. (cf. Are Design Patterns Missing Language Features)
That's an old, weak argument usually put forward by those who either don't understand the patterns much or haven't thought deeply about the capabilities of those languages. For instance read the section on the creational patterns in the Design Patterns Smalltalk Companion for a strong set of reasons why the creational patterns are necessary even in Smalltalk, which is free of C++ constructor sematics --Kyle Brown
Weak? How is it weak? Where's the hole in the argument? I have a similar response to many of the creational patterns: for example, the Abstract Factory Pattern is great in Java, but rarely necessary in a language such as Ruby Language (or, I thought, Smalltalk Language), in which classes are first-class objects and can be passed around and receive messages even if their identity is not known a priori. Likewise, Visitor Pattern is a workaround for closed classes, and thus isn't particularly useful in a language with open classes. To be sure, some of the GoF patterns (like the Command Pattern) are useful in any language, but they are IMHO in the minority. --Marnen Laibow Koser (Arguing With Ghosts)
Although I understand that Gamma et al. did not invent those patterns, I would like to see a variation from the already well known patterns, which IMHO, would be more educative. As the 23 patterns are well known, it is easier to grasp related patterns.
Interesting question. I dug out my Gamma et al, and looked at the back cover. Shows a diagram of the 23 design patterns. After several years of being around patterns, these 23 patterns seem low level -- at the level of two or three objects interacting with each other.
For higher-level patterns, I dug out Plop and Plop 2. My favorite pattern from Plop is #2: A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor.
This is right in line with Alexander's notions, because a Pattern Language is supposed to include patterns for all levels of granularity. You select one that is fairly general to handle a general problem, then use progressively finer grained patterns as you get to more detailed levels of design. So what you say indicates that these software design patterns are in fact patterns in the Alexander sense. - Tom Passin
Then I pondered. Are there other low-level patterns I am familiar with? I thought of parsing and state machines. Gamma et al does have an Interpreter which you can use to parse a simple grammar, but doesn't seem to have other parser or state machine patterns. But I have never coded a parser or state machine with objects, except by using the Interpreter approach. Oh, well.
I pondered some more. The way Visual Works Smalltalk handles copy, by creating an empty new object and then calling the method postCopy on the new object, is very handy. Post Copy Method is my candidate for a useful, simple, low-level pattern not in Gamma.
I think the original author has simply not looked very hard. There are plenty of patterns discussed in Wiki, most can be found with Category Pattern. There is Kent Beck's Smalltalk Best Practice Patterns, there's Martin Fowler's Analysis Patterns, there's the Pattern Languages Of Program Design books. There's even the Shield Pattern, which I would call a fundamental programming pattern.
Just curious: any chance that patterns could come with example unit tests? I don't expect cookie-cutter unit tests in all available languages that would work 100% of the time for everyone, but I am thinking that, given a pattern, perhaps a suite of unit tests written in Java that could be used as a basis for creating your own unit tests? Or maybe just a Unit Test Pattern Language that would describe the different types of unit tests you should expect to use when developing a solution using a particular pattern. The most obvious to me would be for instance in the Singleton pattern, you would have a unit test to ensure that only one instance of the object is ever created, etc. Just a thought.
As a further note, the more I'm exploring unit tests, the more fun I'm having. I'd like to get into patterns more, but I also think that if a particular problem can have a particular architectural solution (a pattern), then that pattern can have a particular set of unit tests. Essentially think of it as a litmus test -- if your architecture can pass the unit tests for ABC, then it can be considered ABC pattern.
The tests don't have to be in code. In fact, I'd prefer them to be in prose form, so that we can then convert them into code ourselves for our particular testing frameworks. Then individuals could look at the pattern, see that there is a prose description of test X but no code in language Y for test X, so they implement the test in language Y and submit it back to the archive for inclusion. Then when you or I come along and want to test we already have the code available.
Of course we customize patterns for our own internal use, but given a standard set of unit tests for a pattern, as long as your code passes those tests you are still considered to be using that pattern.
OK I'm rambling quite a bit here, but hopefully you get the idea...
I think that automated JUnit tests for at least the most obvious and well-known patterns would be a great idea but I also do think that the patterns themselves may serve as the "prose" of a unit test as they fairly well do describe / specify the pattern. Automated JUnit test creation however is quite difficult, given that a pattern can be occluded by other patterns also implemented in one unit, unless you require certain base classes or interfaces to be present. However, with UML and J2SE 1.5 and other languages that support attributed methods, fields and classes, it could be made possible and likewise be automated by some generic test tool - that would at least require some additional configuration or perhaps user-implemented callbacks - call it a framework.
I'm also interested in patterns for unit testing. Developers trying to adopt XP practices find writing the unit tests as hard (or harder) than writing the objects under test. Finding ways to automate testing with things like JUnit requires some pretty good lateral thinking (and patience). I'd be interested to hear about anyone that has done a lot of unit testing and accumulated common patterns that crop up again and again; e.g. how to unit test web page content (ignoring layout). -- Mike Howells
I created an IRC channel solely for the discussion of implementing, and thinking about solving Software Design issues with Design Patterns. The server is located at irc.freenode.net and the channel name is #design-patterns. Please join everyone in this room for anything related to design patterns. -- Jim Hodapp
Considering the Understanding Pattern of a newbie to patterns, could be useful a Top Down Approach for the presentation of Design Patterns. That means that the start point should be the definition of an Abstract Pattern or similar term, in order to wake up the interest to Design Patterns of the reader. If the reader is not conscious, that we are surrounded by patterns, if we, for example, do not point that the nature is build up from lots of patterns, then we will not convince him that easily about the importance of using them. This opinion is based on experience.
Even if this wikiwikiwiki does focus on Design Patterns, their use, their categories etc., and was not thought to be a tutorial for a newbie, it should be a way to attract new people to this way of thinking and acting. Each of us had to have started somewhere with Design Patterns, even the master of this website
To start with, a Software Design Pattern is not something that anyone can �design?since is something that must be discovered.
A Software Design Pattern is essentially a collaboration of classes, or the realization of a use case, but not any collaboration of classes can become a Software Design Pattern.
It must be discovered (determined by somebody) that it is general enough to be useful and applicable to lots of situations in systems design and development.
A few brilliant guys identified the first ones, that were, in retrospective, the easiest to get. As time went by, the ones left were more and more difficult to discover, so what has been said about patterns and time is correct, but the inference produced does not stand. As time passes by, it takes much more effort to discover new patterns. --- Gaston Nusimovich
Just a short note to the Wikizens...
I received the latest copy of the Utne Reader yesterday (Nov.-Dec. 2004) and was pleased to see an article/review in there regarding the publication of volume 3 of Christopher Alexander's The Nature Of Order (volumes 1, 2, and 4 having already been published). The article said that this 2150 page set provides a theoretical basis for the selection of patterns in Alexander's A Pattern Language and for the creation of new patterns.
-- Joe Bradley
May design patterns eventually become subject to Software Patent or Logic Patent issues?
2005-July-30: News flash (scoop goes to slashdot according to news.google.com , which on this topic shows only the slashdot story so far):
"ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
Credit for what appears to be first news report goes to Brent Hailpern, "a researcher at the IBM Thomas J. Watson Research Center, in Hawthorne, New York."
This is a high honor, and reflects as well on all Wiki Zens interested in patterns, and on Ward Cunningham and his c2 wiki, devoted as it is (and as Ward is) to People Projects And Patterns.
Awardee home pages/person pages here on c2:
See especially Gang Of Four, Design Patterns Book, Printable Design Pattern Reference Cards are freely available online
See: Category Refactoring, Hypermedia Design Patterns Repository, Amelioration Pattern, Design Patterns Considered Harmful, Are Design Patterns Missing Language Features, When Is The Use Of Design Patterns Not Appropriate, Software Design Patterns Index (with cross references to different names for the same pattern)
Category Pattern (an index of pattern topics) Category Design
Other external references: en.wikipedia.org (computer_science), Pattern Implementations (Ruby Language wiki)
Does wiki ever talk about the design patterns themselves or just meta-talk about what a pattern even is?
Wiki doesn't talk about anything. People contribute as they want and that builds up over the years. There is a lot of material here.
See original on c2.com