Abstract Factory

tl;dr Patterns, 20 Years Later: The Abstract Factory pattern is often “combined”, conceptually, together with Factory Method into a sort of uber-“Factory pattern”. The two are distinctly separate in the Gang-of-Four literature, however, and for some pretty good reason, as the intentions are different. Subtly so, in some ways, but still different.

Creational Patterns: 20 Years Later

tl;dr Creational patterns specifically deal with the creation of objects/entities in the code. They abstract the instantiation process (meaning that most of the time, they provide an abstraction layer above the use of the raw language facilities to construct an object). They help make a system independent of how its objects are created, composed, and represented.


tl;dr Patterns, 20 Years Later: The Builder pattern has enjoyed some success within the O-O community, particularly among the crowd that sees it as a way to build fluent APIs (APIs which read, more or less, like a natural language, a la English). Builder has a few tricks up its sleeve beyond just fluent APIs, however.

Pattern Implementations

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.

Closure-Based State

tl;dr Patterns, 20 Years Later: With the prevalance of libraries and tools that can peer past access controls (such as Reflection on the JVM and CLR, or the Mirrors facility in Swift), trying to encapsulate private details away from prying eyes can be increasingly difficult. Other languages lack access controls entirely, or the concept of objects. In any of these languages that offer closures, we can hold state within a closure yet outside of the object, rendering it almost entirely inaccessible to outside parties.

Constructor Function

tl;dr Patterns, 20 Years Later: A Constructor Function is a function designed specifically to construct instances of entities (typically objects, although in languages which do not support objects as native types, this will typically be something that masquerades as an object). It is often seen as a variation on a Factory Method, though there is enough variation on the intent that it is worth calling this out as a standalone pattern.

Factory Method

tl;dr Patterns, 20 Years Later: Factory Method is a pattern that is often called by a simpler name hinging on the word “Factory”, a la “the Factory pattern” or somesuch. The GOF language actually has two patterns which each could qualify under that moniker, this one and the Abstract Factory, depending on the intent and the desired consequences.


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”).


tl;dr Patterns, 20 Years Later: Let’s start with everybody’s favorite (and most despised) pattern, the Singleton. Everybody loves the Singleton because, conceptually, it seems the easiest of the lot to understand and (in most post-1995 languages) the easiest to implement. But everybody hates it because its singleton-y nature means it is a natural target for concurrency problems up the wazoo. (And then there’s that whole “Singleton instance vs static methods” debate that goes on.)