Volume 4 and volume 5 in the Pattern-Oriented Software Architecture book series has been released. Volume 4 is about a pattern language for distributed computing and volume 5 is an “in-depth look of what patterns are, what they are not, and how to use them successfully”.
InfoQ spoke to Kevlin Henney, one of the authors of the latest, and seemingly last two books in the POSA-series. We asked Kevlin how come both books were released at approximately the same time?
The original vision was to have a single book that followed the vision for POSA5. The idea was, having introduced the concepts, principles and techniques for writing and organising patterns, we would demonstrate them in action on a large example: a pattern language for distributed computing, along with a pattern story that illustrated its application in practice.
As you might guess, this would make for a very large book!
POSA4 is about distributed systems - what kinds of distributed systems does the book focus on?
…we have tried to document the broad range of architectural concepts that can be found in classic RPC-style systems, contemporary Web applications, message-based systems, mobile computing, classic N-tier systems, and so on. We focus specifically on architectures and architectural knowledge that are based on proven practice....We cover both application and middleware architecture, with an interest in both the development of new systems and the continued development of existing systems.
The style of the book is different from the earlier volumes. POSA4 describes 114 patterns, whereas the three earlier volumes contained 44 patterns altogether. The previous volumes dived deep into each pattern, but since most patterns in POSA4 have been published before in other works, details of the patterns were left out in exchange for exploration of the relationship between them.
By contrast, POSA4 is intended to offer architects and developers a broader, big-picture view of the patterns involved in contemporary distributed computing architecture. The emphasis is on how the patterns relate, where one pattern fulfils the detail of another or provides an alternative to another, so this means that the connections are emphasised and the detail of each pattern is reduced.
However, the lesser level of detail does not necessarily mean that the core idea of each pattern becomes fuzzier:
The patterns are no less accurate for their brevity — and in some cases their descriptions are also more precise — but they are summarised and much of the plumbing detail is omitted.
In order to keep the description of each pattern compact, the book uses diagrammed sketches and pseudocode instead of UML-diagrams and fully blown C++ or Java examples. References are given for readers who wants to dive deeper into a particular pattern.
We asked Kevlin if there were any particular patterns that he felt had been lost or misunderstood, that they were particularly pleased to bring forward in the book?
There are a couple of patterns that are quite humble but have some significant and very influential consequences in modern design approaches.
The first is what we have termed Explicit Interface, which in essence is the notion of factoring out a separate interface, decoupling it fully from its implementation. The approach is appropriate for declared type systems and has existed since RPCs, and we find it commonly in modern statically typed languages, namely the ‘interface’ construct. However, the point of the Explicit Interface pattern is the design sensibility behind using such mechanisms and focusing on a separation of concerns. In spite of an increase in interface-based programming in recent years, many programmers still use pure interfaces — whether in the form of the ‘interface’ construct or in terms of fully abstract classes — in a more coupled fashion than necessary, if at all.
The second is the idea of a Context Object. Like the idea of interfaces, the idea of context objects has been around for a long time (it’s present in Scheme’s eval procedure and can be found lurking in the Gang-of-Four Interpreter pattern), but it has only recently been documented and reasoned about as a pattern in its own right. The write up in POSA4 is just the latest in a line of many different write ups, which includes one by me and a separate one by Doug! A context object allows an object, component or whole subsystem to be parameterized with execution details, such as configuration, credentials, lookup services, etc, independently of other parts of the system. This isolation promotes independence between components, simplifies testing and eliminates a class of problems and/or performance bottlenecks that might otherwise be introduced in a multi-threaded environment. It is often seen as an antidote for many of the problems that using Singleton brings in its wake (and, as an aside, Singleton was one pattern we did _not_ include in the book :->).
The fifth and last book in the series is a book about patterns and pattern languages. It shows how to document, organize and use patterns; how to build relationships between patterns and how to turn those relationships into a pattern language.
Before POSA5 the conceptual discussion of patterns was scattered across numerous works and the heads of various individuals, both within and outside the patterns community. Each book, paper or presentation that presents a set of patterns introduces the pattern concept with a different slant, one that may differ from others anywhere from slightly to radically. Different sources place different emphasis on different aspects, such as the context in which a pattern occurs, the use of pattern languages, the role of forces in a pattern, the social or technical goal of patterns, and so on.
Kevlin concludes:
POSA5 […] is for practitioners who are interested in exploring the pattern concept further. In other words, this book is targeted at software practitioners who have already had exposure to patterns in some form — whether GoF, POSA, Core J2EE, etc — and want to know more about patterns.
