A group of DesignPattern
s, 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
In some cases, the handle and body have a fixed one-to-one relationship; in others the body associated with the handle might change.
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. :)
for discussion of problems with this pattern.
Also known as WrapperObject