A group of Design Patterns, 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 Wrapper Pattern). 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 Handle Body Pattern 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 Handle Body Pattern 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 Adapter Pattern), but it is also true when the interfaces are the same or very similar.
For example, consider Facet Pattern composed with Remote Proxy -- if Facet Pattern is applied first, then it is the remote machine that is responsible for enforcing the facet. If Remote Proxy 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 Handle Body Pattern 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 Cee Plus Plus can implement these (many Design Patterns are designed to get around C++ limitations), you just have to do more typing. :)
See Handle Body Pattern Problem for discussion of problems with this pattern.
Also known as Wrapper Object
See original on c2.com 