Programming .NET 3.5

The Chain-of-Command Pattern

This very powerful design pattern allows you to separate command objects from helper (processing) objects, and to create objects that have both responsibilities and a place in a sequence of actions. This is very useful in workflow or other sequential situations.

The Chain-of-Command pattern must be used with caution, however, because programmers moving from procedural programming to object-oriented programming are wont to create a single master commander object and zillions of little processing objects, recreating the procedural pattern that object-oriented programming replaces!

Each processing object contains logic that describes the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain. Thus, each object is neatly encapsulated and has a single, well-defined set of responsibilities.

For this pattern to work, it must be extensible. That is, a mechanism must exist for adding new processing objects to the end of the chain.

A well-implemented Chain-of-Command pattern (Figure 8-21) can promote loose coupling, which is integral to the kind of n-tier programming that .NET 3.5 fosters and that makes for sustainable software.

A Chain-of-Command Example

To illustrate this pattern, we're going to (grossly) simplify the chain-of-command requirements to allow liftoff of a space shuttle.

ora: Trees of Responsibility

There is an advanced variation of this pattern in which handlers are divided into ...