Context:

Two alternative classification schemes seem equally valid (e.g. stream opened for either input or output and also encapsulates a specific device). A replacement for multiple inheritance, possibly with dynamic classification.

Challenge:

To base the design on one classification while retaining the latter. Possibly, to allow the latter to vary during object lifetime.

Skill:

Participants:

Behavior:

Basic services used by client (e.g. Stream).

Particular Behavior:

The complete set of services to be used by client, typically non-polymorphically (e.g. Input Stream).

Implementation:

A set of primitives to be used internally by Behavior (e.g. to fill buffer).

Concrete Implementation:

Methods for the set of primitives to be used internally by Behavior.

Signature:

Behavior contains Implementation. Client uses Concrete Behavior and typically provides the Concrete Implementation.

Known issues:

Since Implementation typically features the entire spectrum of primitives needed by particular Behaviors, the signing its provision to the client and possibly allowing its replacement during Behavior's lifetime may invalidate the Concrete Behavior (e.g. resulting in an Input-Stream with Buffer open for output). widely using multiple inheritance instead would not allow that to happen, it would not allow dynamic classification (where desired) in the first place.

Used by:

I/O libraries.

Source:

GOF.

Scope:

General.