Also Known As: Semantic Wrapper [O’C00], Sweeping it Under the Rug [FY00].
Intent Wrap a legacy system to export the right abstractions, even if they are not reflected in the existing implementation.
How should the new target system access legacy services during the migration process?
This problem is difficult because:
- The target system is not yet complete so you must rely on legacy services during the migration.
- The legacy system does not present the interfaces you need for the target system.
- Implementing new components directly in terms of legacy components will bias the target towards the legacy architecture and design.
Yet, solving this problem is feasible because:
- You don’t have to access the legacy services directly.
Identify the abstractions that you want to have in the new system, and wrap up the old software to emulate the new abstractions.
Consider, for example, a procedural graphics library that will be used within an object-oriented system. It will be too costly and time-consuming to reimplement the library in an object-oriented way. It would be easier to wrap it as a utility class (i.e., as a class with static methods but no instances), but it would be wiser to write a slightly thicker wrapper that presents a truly object-oriented interface, but is implemented using the underlying procedural abstractions. In this way the new system will not be polluted by legacy abstractions.
- It is easier to wean the target system from legacy services if they can use appropriate abstractions from the start.
- You reduce the risk that the legacy design will adversely influence the new target.
- The new interface may not be stable, so developers may be reluctant to use it.
- It can be hard to resist the temptation to simply wrap the procedural abstractions as utility classes.
Alan O’Callaghan [O’C00] presents this pattern as “Semantic Wrapper” briefly in the context of the ADAPTOR pattern language, which addresses migration of large-scale business-critical legacy systems to object-oriented and component-based technology.
Present the Right Interface frees you from thinking in terms of the legacy design and makes it easier to consider alternative approaches.
Present the Right Interface superficially resembles an Adapter, since both use wrappers as their implementation technique. An Adapter, however, adapts an incompatible interfaces to another interface expected by its clients. Present the Right Interface, on the other hand, introduces a new, more suitable interface to a legacy component.
Be sure to Deprecate Obsolete Interfaces.
If the new interface implemented by the Present the Right Interface is not stable, you should Distinguish Public from Published Interface.