Structure of Pattern Pages

The Structure of the Patterns Pages

The purpose of this repository is to serve as a central clearing house for patterns in software. We impose a general scheme on all contributions, to make the repository more understandable, and to ensure that nothing essential is missed. This structure follows our general notion of what a pattern is, and how it can deliver the maximum value to us. We will being by describing this notion.

Patterns as Collections of Forces

We believe that patterns have been largely misunderstood, and that as a result of this much of their value has not been realized for most developers that study them.

The original patterns book "Design Patterns: Elements of Resuable Object-Oriented Software" (by Gamma, Helms, Johnson, and Vlissides, aka "The Gang of Four") has in its very subtitle the roots of this misunderstanding. We do not believe that patterns are simply "reusable software." David Bernstein (one of our instructors) puts it this way: "If patterns were reusable software, the Gang of Four would have written a software library, not a book."

The "Design Patterns" book demonstrates the patterns by showing //examples// of them, which is a perfectly legitimate way to introduce someone to a pattern, but if these examples are taken too literally will vastly limit the situations in which they will apply. Therefore, while we find the GoF examples very useful, we do not think of these examples as "being" the patterns.

We present the patterns here in the way we think of them, and in the way they have been the most useful to us: as collections of forces.

By "forces" we mean the knowns, the driving issues, the critical decisions, and the understood effects of what we do. We divide these forces, for each pattern to be discussed, into three categories:

Contextual Forces

(How we know to consider a given pattern)

Motivation: Why this pattern is used, what it's for, the domain problem it solves.

Procedural Analog: How we would have solved this same problem procedurally.

Non-Software Analog: A way of seeing the pattern conceptually, from life experience.

Implementation Forces

(How to proceed once we decide to use a pattern)

Example (UML and pseudo-code): A concrete instance of the pattern (which is not the pattern, but only an example).

Questions, Concerns, Credibility checks: Those issues that should come into the discussion once the pattern is suggested as a possible solution.

Options in implementation: Various options that are well-known in implementing this pattern. Often the various implementations arise out of the questions and concerns that accompany the pattern. Also, different implementation options may carry different consequent forces (see below).

Consequent Forces

(What will happen if we use a pattern)

Testing issues: Testing wisdom that accompanies the pattern. These are hint, tricks, and tips that can make patterns, which usually depend very heavily on delegation, easier to test. They depend on a reasonable knowledge of Mock and Fake objects, which are covered in the sections on testing and test-driven development.

Cost-Benefit (gain-loss): What we get, and what we pay when we use this pattern. Understanding these issues is a key aspect of making the decision to use, or not to use a pattern. Patterns are as just valuable to us when they lead us away from themselves.

Code examples will be presented in a Java-like, C-Sharp-ish pseudo-code style that will hopefully readable by all. The purpose of both the code and UML examples is to illustrate, not to define. Patterns are not code, and are not diagrams; they are collections of forces that define the best-practices for solving a recurring problem in a given context. We provide code and UML examples because many people understand concepts better when they are accompanied by concrete examples.

Similarly, the procedural analogs are not meant to be literally applied: one would not use a Strategy pattern every time one sees a branching conditional in procedural code. The purpose of the analog is to allow us to use the part of our brains that understand procedural/algorithmic programming to suggest a possible pattern alternative, but only to ensure that we consider all of our options before making an implementation decision. The decision is, and will always be (in my opinion), a human one.

The patterns that help to define our profession are not static, but are rather a living, changing thing that we must always seek to improve and expand upon. This must be a community effort.

To this end, my organization has created this "repository". You are welcome here! Let us know your views, contribute the things you have learned, and share the wealth.