A wrapper insulates a service provider (e.g., a server or component) from all service consumers. Wrappers typically accomplish this by taking on the identity of the service provider.
Other well-known names for the mechanism, if any.
A scenario that illustrates a problem and how the different elements of the mechanism solve the problem. The scenario will help you understand the more abstract description of the mechanism below.
What are the situations in which the mechanism can be applied? What are examples of poor designs that the mechansim can address? How can you recognize these situations?
- An applicable situation
The elements participating in the mechanism and their responsibilities.
- Participant Name: Responsibility for what
How the participants collaborate to carry out their responsibilities.
- [Collaboration]
How does the mechanism support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?
- Description of consequence
What pitfalls, hints, or techniques should you be aware of when implementing the mechanism? Are there language-specific issues?
- Description of Bullet
Examples of the mechanism found in real systems. Try to include at least two examples from different domains.
Wrappers are a particular type of component intermediation. Wrappers are similar to the Decarator software pattern.
Back to the Adaptation home page. This page maintained by Peyman Oreizy (peymano at ics.uci.edu). Last updated on [an error occurred while processing this directive].