Design Patterns – Did the Gang of Four Thoroughly Explore Pattern Space?

I was Editor of Software Development magazine when the Gang of Four book came out and I can say with total confidence that unit-testing was not a widespread practice in 1994, when Design Patterns was originally published.

In 1994, C++ was the most commonly used object-oriented language, and most people programming it were coming from a C background. One of the "thinking in objects" things that people simply didn't have is the idea of hundreds or thousands of entry points into your program. You thought about the main(). If you worked on a large project, you might have a (usually quite elaborate) makefile to create a module-based program. But "unit-testing"? Starting a process, building the necessary memory context, executing it, and tearing it down, on a per method basis? That was very radical.

Java made multiple-entry-point programming more obvious. By the time of the original Dot-Com boom, unit-testing was a well-known technique, but it was really JUnit (circa 2001?) that caused it to catch fire and become a universal practice.

Although Strategy and the general concept of programming to an interface were part of GoF and the mid-90s zeitgeist, the idea of injection came quite late to the party (circa '03-'05?). Honestly, my gray hairs are still quite dubious about that aspect of DI ("Get off my lawn, you darn configuration files!").

The main reason to use a pipeline design is that you want to decouple the stages. Either because one stage may be used in multiple pipelines (like the Unix shell tools), or because you gain some scaling benefit (ie, you can easily move from a single-node architecture to a multi-node architecture).

In either case, each stage in the pipeline needs to be given everything that it needs to do its job. There's no reason that you can't use an external store (eg, database), but in most cases it's better to pass the data from one stage to another.

However, that doesn't mean that you must or should pass one big message object with every possible field (although see below). Instead, each stage in the pipeline should define interfaces for its input and output messages, that identify just the data that stage needs.

You then have a lot of flexibility in how you implement your actual message objects. One approach is to use a huge data object that implements all the necessary interfaces. Another is to create wrapper classes around a simple Map. Still another is to create a wrapper class around a database.