Decorator Pattern

Related Sites

There is one feature that has me stumped. These are termed 'effects' or 'shadows' in MUD parlance.

Given a player object, another object can 'cast' a 'shadow' on it that will intercept all messages passed to the player object. It will then handle these as desired, and may pass them on to the object with or without alteration.

[...]

The best description I can find of it is dynamic inheritance, since the shadow object appears to inherit from the shadowed object, override some of its methods and place itself wherever the shadowed object was previously referenced. This representation seems tortured to say the least.

Tim Ottinger replied:

I'm not a mud player, but this sounds very much like the "decorator" to me. You should check out the pattern (from Design Patterns) and see if it really is applicable, but it sounds right to me from this short introduction.

[In this pattern, a decorator (shadow) is inherited from the same abstract class as the decorated object (player). The decorator holds a pointer to the decorated object, and forwards messages to it. The decorator may add its own behavior to some or all messages. -YS]

[...]

It's a simple matter of delegation, which is heavily used in OOD. A lot of people call "the building of a logical object by the assembly of physical objects" composition. Composition has a few other meanings (and it seems that overloading terms is an OO attribute).

Vince Huston, A short description of the Decorator pattern

Patterns Home Page

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides,
Design Patterns -- Elements of Reusable Object-Oriented Software