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.
A Builder implementation in C#.
A Builder implementation in Java.
A Constructor Function implementation in Scala.
A Constructor Function implementation in Java.
A FactoryMethod implementation in Swift.
A Builder implementation in Swift.
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.
A Constructor Function implementation in Swift.
A Closure-based State implementation in Swift.
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.
A Closure-based State implementation in F#.
A Closure-based State implementation in Java.
A Closure-based State implementation in C#.
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.
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.
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.
A Singleton implementation, in C#.
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”).
A Singleton implementation in Scala.
A Singleton implementation, in Java.
A Singleton implementation, in Swift.
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.)
tl;dr 20 years ago, the “Gang of Four” published the seminal work on design patterns. Written to the languages of its time (C++ and Smalltalk), and written using the design philosophies of the time (stressing inheritance, for example), it nevertheless spawned a huge “movement” within the industry. Which, as history has shown us, was already the hallmark of its doom—anything that has ever become a “movement” within this industry eventually disappoints and is burned at the public-relations stake when it fails to deliver on the overhyped promises that it never actually made. It’s time to go back, re-examine the 23 patterns (and, possibly, a few variants) with a fresh set of eyes, match them up against languages which have had 20 years to mature, and see what emerges. (Spoiler alert: all of the original 23 hold up pretty well, and there’s a lot of nuance that I think we missed the first time around.)