Let's talk a bit about the various pattern implementations, the languages in which they are being written, and what to "get" out of them.


The "implementation" or "examples" section of any pattern discussion holds several goals (and a few "anti-goals"):


In general, there's a long list of languages I will use to define some example implementations of the patterns in the catalog. Note that while this isn't an "ordered" list, meaning I will probably do implementations in a seemingly-random order, the hope is that when this is all said and done, the list of pattern implementations will range across the following:


An imperative, strongly-typed object-oriented language for native platforms. This was one of the original laguages used for examples in the GOF book, and it would seem highly useful to revisit them now, particularly given the changes that C++ has seen since 1995.

Specifically, I will be looking for opportunities to incorporate C++11 and C++14 features into the pattern implementations, particularly templates (and the STL), exceptions, code blocks, and more. I will try to remain aware of the idiomatic approach to some of these, but since some are still freshly-minted, there may be no established idioms upon which to draw.


An imperative, strongly-typed object-oriented language for the LLVM (iOS/Mac OS X) platform. For the most part, Swift is pretty straightforward as a GOF pattern implementation language, since it more or less finds itself in the same space as its kin, C++, Java and C#. The example implementations were written starting after Swift 2.2 was released; Swift 3.0 is on the horizon, but no clear definition (as of this writing) as to what that feature set will/won't turn out to include.

Note that Swift has no "abstract class" or "abstract method" in the Swift 2.2 language, so as a result, where the code may require some form of method-definition-but-deliberately-without-an-implementation, we will use Swift's preconditionFailure method instead.


An imperative, strongly-typed object-oriented language for the JVM platform. You can't really mention Swift without also covering Kotlin; where Swift is the default language for doing iOS development, Google has made Kotlin the same for Android. And honestly, Kotlin is quickly becoming my go-to choice for doing things on the JVM, even over Java itself.


An imperative, strongly-typed object-oriented language for the CLR platform.


An object/functional, strongly-typed language for the CLR platform.


An imperative, strongly-typed object-oriented language for the JVM platform. Java follows C++ in the object-oriented tradition, and as such is pretty closely relatable to the GOF patterns, with a few modifications. Java lacks a number of the syntactic features of the C++ family tree, but the gap is smaller now (as of 1.8) than it was fifteen years ago. For the most part, since lambdas and function literals are still very new in the Java ecosystem, pattern implementations will show both "with and without" scenarios, at least until such point as doing so gets either (a) tiresome, or (b) less necessary (owing to greater proliferation of lambdas/function literals through the Java ecosystem).


An object/functional, strongly-typed language for the JVM platform.


An imperative, weakly-typed object-oriented interpreted language.

JavaScript runs in browsers and on servers (using NodeJS), and will probably continue to extend its reach to a variety of other places as time goes on. JavaScript has been described in some quarters as being a functional language, but given that it lacks key critical functional features (partial application of functions, immutability by default), I do not consider it as such. I will also include implementations of ECMAScript6- and 7-oriented code, where it seems appropriate or important.


An imperative, weakly-typed object-oriented interpreted language. Python is becoming ridiculously popular for a large number of reasons, and despite my earlier misgivings about the use of significant whitespace to denote scope blocks, after having toyed with it for a while, I'm starting to come around to the idea that maaaaaybe it's not so bad. It has some functional concepts like many of its peers, but again, it's not really a functional language because it lacks some of the critical things (immutability by default, partial evaluation, and so on) that make functional languages powerful. Useful, all the same, but not a functional language.


An imperative, weakly-typed object-oriented interpreted language. Ruby is, in many ways, akin to JavaScript in its approach and feature list. It has just enough functional-like features (function literals, for example) that it can mimic some functional features, but like JavaScript, it cannot be called a "functional language" akin to Haskell or ML.

Other languages

I also plan to explore some other languages, sometimes as an intellectual exercise (and as a way to practice writing code in those languages), sometimes because I think the language is going to gain more traction, and sometimes just because I'm intrigued. That list includes, but is not limited to:

Functional languages


Dynamically-typed languages

And of course I reserve the right to add a few more languages to the mix, if they're interesting. Because, in a lot of ways, while I hope that readers get a lot out of this, this whole exercise is more for me than anybody else.

Last updated: 02 July 2016

Tags: patterns   creational patterns   structural patterns   behavioral patterns