views:

168

answers:

4
+1  Q: 

Non-GOF patterns

How many design-patterns can you name that are not GOF patterns?

Do you have any web-link that lists those names?

+4  A: 

The Wikipedia page is always a good place to start. The "In Design Patterns" column in the linked table tells you which patterns were in the GOF book, and which weren't.

Brian
A: 

The wikipedia list indicated by Brian is indeed rather comprehensive. I was surprised to find nether...

mjv
Well, you know, Wikipedia *is* editable...
Brian
Borg is pretty Python-specific. The strongest design patterns are generic across languages.
Paul McGuire
@Brian, rightly so! In fact I occasionally contribute on WP and may just do so re. this pattern (I'll just have to read the current list thoroughly, so many patterns show-up under different names and/or with ever so subtle differentiators...
mjv
@Paul McGuire: true, Borg is more readily implemented in Python, though it can be done elsewhere (I did so in C#). This said, the GoF was quite aware of the importance of the language context in which a DP is implemented and/indeed needed or not. Quote: "The choice of programming language is important because it influences one's point of view". Borg is interesting case in point, whereby easily implemented, it or singleton are rarely needed in Python, unlike say in Java where module level methods don't exist.
mjv
+3  A: 

For what its worth, Design Patterns on Wikipedia has a list of design patterns, including information on whether those patterns appear in the GOF book.

Off the top of my head, GOF excludes a whole category of design patterns related to concurrency, including double-checked locking, spin locking, and pretty much everything regarding pi calculus.

Additionally, some patterns seem to follow naturally from other programming paradigms:

  • There are lots of patterns in functional programming which don't appear in the GOF book. A frequently used design pattern involves the use of accumulator variables to transform non-tail recursive functions into tail-recursive functions. Additionally, the concept of a monad or what its used for would have been entirely alien to the original developers. Immutable objects are entirely absent from the GOF book.

  • Lisp's macro system could probably be considered a design pattern, or indicative of one.

  • I've never used a stack-based programming language, but I bet Forth programmers have plenty of tricks to get their algorithms to map cleanly to the stack.

  • In an abstract kind of way, you might consider the relationships between tables in a relational database schema a kind of design pattern: 1-to-many, many-to-one, many-to-many, one-to-one. More than that, there are predictable ways of modeling hierarchial data, and here's a fairly cookie-cutter way of modeling tagged unions in SQL.

  • etc.

Juliet
+1  A: 

there are only a few other oo design patterns. one is null object (i forget the other). these plus the 23 gof are sort of orthogonal and complete. there really are no more. everything else is mostly just a combination of these 25 or so.

Ray Tayek