Context (Object Behavioral)

Define a wrapper object that encapsulates all aspects of an operation, including details that may not be directly related to that operation. Context allows an object or graph of objects to be handled in a single logical unit, as part of a logical unit of work.

Motivation

Frequently an operation, which consists fundamentally of inputs and a generated output, requires additional information by which to carry out its work. In some cases, this consists of out-of-band information, such as historical data, previous values, or quality-of-service data, which needs to travel with the operation regardless of its execution path within the system. The desire is to decouple the various participants working with the operation from having to know everything that is being "carried around" as part of the operation.

In many cases, a Context will be what is passed around between the various actors in a Chain of Responsibility (223).

Consequences

I'm not sure yet.

Known Uses

Several distributed communication toolkits make use of Context or something very similar to it. COM+, for example, uses the notion of Context as a interception barrier, allowing for a tightly-coupled graph of objects to be treated as an atomic unit, synchronizing multi-threaded calls into the context, also called an apartment. Transactions are traced as they flow through different parts of the system, such that each Context knows the transaction ID it was associated with and can allow that same transaction ID (the causality) to continue to flow through, thus avoiding self-deadlock.

Web Services also make use of Context, using the SOAP Message format as a mechanism in which out-of-band information, such as security headers and addressing information, can be conveyed without "polluting" the data stored in the message itself. WS-Security, WS-Transaction, WS-Routing, among others, are all examples of specifications that simply add headers to SOAP messages, so that other "processing nodes" in the Web service call chain can provide the appropriate semantics.

(I know there are others, but nothing's coming to mind at the moment.)

Related Patterns

Context is often the object passed along a Chain of Responsibility; each ConcreteHandler in the Chain examines the Context and potentially modifies it as necessary before handing it along to the next Handler in the Chain.

Context is also used as a wrapper for a Command object, providing additional information beyond the Command itself. The key difference between the two is that Context provides out-of-band information that the Command object may not even know is there, for processing by others around the Command.

Context from Ted Neward

This is standard way of executing Abstract Syntax Tree.This pattern( Not sure to call this as a pattern but still :-)) ). See interpreter pattern in Eric Gama's book. Ratinale behind this object ( Context) is to ensure that all relavant information about execution of a syntax tree graph is available globally ( globally to that particuler execution).

I use this pattern all the time. Nice that it has a name now ;-)

Consequences include:

1. Call performance is reduced because more data is passed
2. Slight increase in code complexity

Knows uses:

I'd like to add:

-Context is quite often used to add state to stateless protocols.
-Context can be used to set the software in a particular mode of operation

I agree that Context is a design pattern. An interesting implementation can be found in the Morph framework at

http://morph.sourceforge.net

It provides context inheritance capabilities, allows any context to be exposed as a Map, and provides an easy mechanism to retrieve and information from the context using whatever form (class) is most convenient.