25 August 2013

The overall pattern catalog. The goals of this enterprise are admittedly audacious: to not only re-visit the original Gang-of-Four patterns, bringing them "up to speed" with modern languages and idioms, but also to incorporate concepts from functional (and object/functional hybrid) languages.

Note that these are "design patterns", meaning they are at the level of software implementation design, not "architectural" patterns (such as what we might find from Martin Fowler's "Patterns of Enterprise Application Architecture").

This roughly follows the same format as the original Gang-of-Four patterns catalog, but with a few changes.

This catalog is a continual work-in-progress; as more patterns are added to the catalog, their links will become active. Readers are encouraged to comment liberally, provide alternative implementations and/or suggest different language-specfic idioms, and/or participate in whatever fashion feels meaningful.

By the way, this will take time to flesh everything out, so please, be patient. I promise I'm trying to get to these as fast as I can without doing an ugly job of it.

Creational patterns

Patterns which specifically deal with the creation of objects/entities in the code.

Structural patterns

Patterns which describe the structural (usually compile-time-related, in langauges which are compiled) relationship between one entity and another.

Behavioral patterns

Patterns which describe the runtime relationship between one entity and another.

Additional pattern language(s)

I've run across a few that I haven't yet been able to categorize in the above, and I don't want to lose track of them.

I also plan to go back through some of my patterns books (such as the "Pattern Languages of Program Design" books that were published in the late 90's/early 00's) and cherry-pick some that seem to fit in the above categorization scheme.

In other words, this is going to be a long work in progress.


I have notes around the different pattern implementations (and the languages in which I am choosing to do them) here. However, the implementations will always appear in a separate page from the pattern itself, owing to the fact that (a) I want to explore several languages around each pattern, and it would make each pattern page extremely long to have them all in one place, but also (b) patterns can and should be language-independent, and therefore it makes sense to me to split them apart.