Handle Body Pattern

A group of DesignPatterns, in which the implementation of something (the "body") is separated from its interface by means of a level of indirection (the "handle").Client code operates on the handle, which then operates on the body; either by simply forwarding/delegating requests or by adapting a protocol. We can say that the handle wraps the body (hence the alternative name WrapperPattern). It may modify or suppress some messages, depending on the purpose of the wrapping. The object that is being wrapped may cooperate, but more commonly it has no knowledge that it is being wrapped.

Examples of the HandleBodyPattern include:

In some cases, the handle and body have a fixed one-to-one relationship; in others the body associated with the handle might change.

A HandleBodyPattern can be treated as a function that maps from the body to the handle. These functions can be composed. In general, the order of composition matters. This is obvious when the handle presents a different interface to the body (for example in AdapterPattern), but it is also true when the interfaces are the same or very similar.

For example, consider FacetPattern composed with RemoteProxy -- if FacetPattern is applied first, then it is the remote machine that is responsible for enforcing the facet. If RemoteProxy is applied first, then the client machine is responsible for enforcing the facet. The latter option is more likely to allow the facet restriction to be bypassed.

Construction of the various forms of HandleBodyPattern is greatly enhanced by a good macro processor or a language with meta-capabilities (which can automate much of the typing). However, even a language such as CeePlusPlus can implement these (many DesignPatterns are designed to get around C++ limitations), you just have to do more typing. :)

See HandleBodyPatternProblem for discussion of problems with this pattern.

Also known as WrapperObject

CategoryPattern