This year, 2024, will mark the 30th anniversary of the publication of “Design Patterns: Elements of Reusable Object-Oriented Software”, the famous book by the Gof, or Gang of Four, as its four authors are known: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
It’s impossible to overlook the fact that, even today, Design Patterns are part of the fundamental culture of object-oriented design. However, things have moved on a great deal in the last 30 years, and it would be fair to ask how such a “relic” can still be of any importance today.
There are countless references (reprints, articles, blog posts, etc.) dealing with these patterns, unfortunately not always very clear and sometimes not at all up to the standard of the original. The book can come across as arduous, and for good reason: it is not aimed at novice object designers. This is mentioned right from the first sentence of the preface: “This book isn’t an introduction to object-oriented technology or design” (yes, I do read the prefaces to books, they are often full of good information for understanding the motivation and context that led to them being written 🙂 ).
This first paragraph tells us that you need both reasonable competence in at least one object-oriented programming language and some experience of object-oriented design. Reading it (and completing it) requires a considerable investment, a fair amount of effort and perseverance. Here again, in the preface, the authors give us a word of warning and encouragement with a “It’s OK if you don’t understand the whole book on the first reading, we didn’t understand it on the first writing either!
They remind us (and the title too) that this is a catalogue. It’s not meant to be read once before being put on a shelf. It’s meant to be referred to again and again, it’s meant to be re-used, it’s meant to profoundly change the way we think about objects.
With all these warnings, it is understandable that it is still rather difficult for many people to answer the classic interview question: “Name a few Design Patterns, other than Singleton, and explain them”.
However, these 23 historical patterns are only a first list. The authors, again in the preface, tell us that they do not consider this collection to be complete or static. It is rather a “record of our thoughts on design”, they write, still in the preface. In fact, several other catalogues of patterns, and not just Design Patterns, have appeared since then.
But to answer the initial question (“Does it still matter today?”), we need to look at the context and understand the origins of all this.
The book had a long gestation period (this is also indicated in the preface), as work began as early as 1990. At that time, Java did not yet exist. The examples described are in C++ and Smalltalk, the two flagship object-oriented languages, and we were still at the beginning of the wave, the time when any new system had to have the two OOs in its name in order to get any attention. UML didn’t exist either, class diagrams were in OMT and when the book was published in 1994, the web would only be in its first year of public existence. More importantly, the object principles, including the famous SOLID principles, had not yet been formulated.
To understand the motivation and the way in which these Design Patterns have been catalogued, this time you have to go and read the first introductory chapter, “What is a Design Pattern?” and ask yourself who this Christopher Alexander is who is said to have said (or rather written): “Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to this problem, in such a way that you can use this solution a million times, without ever doing the same thing twice”. With a bit of internet research, we discovered that the notion of pattern and this idea of a catalogue comes straight from another even older best seller: “A pattern language”, published in… 1977. The full title is ‘A Pattern Language: Towns, Buildings, Construction’ (note that there are similarities even in the title). A best seller on architecture and town planning, the ‘real’ one, that of buildings and towns. This book was apparently very much in vogue in design and engineering circles in the 80s. It contains no fewer than 253 patterns, intended to provide a language for everyone, not just architectural professionals, to use to improve their neighbourhoods with their neighbours, or to design their own homes, offices or buildings. Put like that, it sounds rather abstract (another similarity). For a long time, I cited an example for which I no longer had the exact source, but which is indeed one of the 253 patterns: pattern 180: Window Place. This pattern states that it is necessary (and not just a luxury) to have a comfortable place near a large window in your rooms. If you don’t, there’s a tension – possibly minor but inevitable – between the desire to be comfortable and the desire to have light.
The pattern describes a problem and a “solution” that can be applied a million times without reproducing exactly the same thing. There are many images and illustrations of such Window Places on the web, and it’s interesting to note that they generally make you want to go and relax there with a good book.
This, then, is the general idea that has driven the GoF since 1990: to observe numerous IT projects, identify a list of recurring problems and describe the essence of the elegant and remarkable solutions that experienced designers have arrived at, independently, after several attempts (the patterns were selected according to the criterion that the instinctive approach used by a novice designer to solve the problem is generally not a flexible and reusable solution).
Note here that the important feature sought at the time was a solution that improved the flexibility and reusability of the code. The famous reusability is often sold by marketing to promote object orientation. Things have changed considerably since then. Long gone are the days when developing in-house frameworks was the rule. Today, patterns are embedded directly in languages (think of Iterator, Observer, Listener in Java) and in frameworks (just look for classes and interfaces in Spring and in Java containing words like Factory, Adapter, Bridge, Strategy, Builder, Chain, Command, Composite, Decorator, Facade, Prototype, Proxy, Singleton, State, Template, Visitor… almost all of the GoF’s 23 Design Patterns are present in one way or another, and this is proof of their timelessness, emphasised by Alexander and obviously sought after by the GoF’s four partners.
So these problems are still with us, and it’s important to be aware of them, because that’s the whole point of patterns: to recognise the problems encountered in order to find the essence of the right solution, or at least a reflection on possible solutions, without spending time reinventing it in the wrong way. And to do that, you need to have at least looked through the catalogue once, if you haven’t understood everything.
To help us, the authors have grouped them historically into 3 categories: Creational, Structural and Behavioral Patterns.
I tend to explain these three categories by relating them to the two fundamental principles of object-oriented design and design in general: weak coupling and separation of concerns.
Creational Patterns address the first major concern that is virtually ignored in notations such as UML. When we talk about objects or draw a diagram, we always think about assembling objects or making them communicate, but we never talk about their creation. The only diagrams that deal with creation are sequence diagrams with creation messages. On the one hand, instance creation is extremely language-specific (a class message in Smalltalk, a new operator in C-inspired languages) but, above all, this operator introduces a very strong coupling into the code. Behind a new, you can only indicate a real class to instantiate. So it’s not surprising that the authoring patterns describe five standard ways of delegating, forbidding, moving and transforming new: Singleton (forbidding), Factory Method (isolating new in a method so that it can be redefined in a subclass), Abstract Factory (moving new to another class),
Builder (decompose the new of a complex object to enable its construction to be scripted) and Prototype (replace the new with a copy of an existing instance). It should be noted that other patterns have since been identified for this subject (Registry, Dependency Injection, etc.).
Structural Patterns deal with a completely different problem: the separation of concerns. Object design encourages us to make simple, single-purpose objects. An object that does too many things or has too many attributes lacks cohesion and will be difficult to maintain and evolve. So the question becomes “How do we assemble these small, specialised objects to build complex systems? I usually summarise this with the following question: “How do you build cathedrals with simple cut stones, mortar and tree trunks? You have to put all this together precisely to solve numerous problems of tension and harmony if you hope to build a cathedral that stands up. Structural patterns help us to adapt, transform and assemble.
Behavioral Patterns deal with almost the same problem, but from the point of view of processing. How can you do complex processing if the objects are single-purpose and only do simple things? You have to divide up complex tasks, delegate and coordinate the flow of execution. This is the role of behavioural patterns.
All these patterns are part of the object-oriented culture. They change the way we think, design, reason and communicate. The multi-paradigm has been in widespread use for some time now. Java has followed the trend by introducing the functional paradigm since Java 8 and is in the process of adding data-oriented programming. Admittedly, this was neither the subject nor the trend 30 years ago. Each paradigm comes with its own patterns and it’s important to understand that even a superficial knowledge of the Gof Design Patterns is more the beginning of a change in mindset than a recipe to be known and applied in a given situation. So, yes, it’s important to know these patterns, at least the problems they solve, and to try to understand them. The Guide to Readers section suggests starting with Abstract Factory, Adapter, Composite, Decorator, Factory Method, Observer, Strategy and Template Method.
So, if you haven’t taken the first step yet, find a good Window Place and stick with it – it’s really worth it. All the best!
