Also Known As: Published Interface [O’C00].
Intent Facilitate parallel development by distinguishing unstable “published interfaces” from stable “public interfaces”.
How do you enable migration from legacy interfaces to new target interfaces while the new interfaces are still under development?
This problem is difficult because:
- You want to enable migration to the new target system as early as possible.
- You do not want to freeze the interfaces of new target components too early.
- Changing the interface to a component that is widely used will slow down development.
Yet, solving this problem is feasible because:
- You can control the status of the interfaces you provide.
Distinguish between public interfaces of components that are available to the rest of the system, and unstable “published” interfaces of components that are available within a subsystem, but are not yet ready for prime time.
Since “published” interfaces are not supported by any programming language, you may have to use naming conventions, or abuse other features to achieve the desired effect.
- In Java, consider declaring such interfaces as
protected, or giving them package scope (undeclared). When the interfaces stabilize, you may redeclare them as being
- In C++, consider declaring components with published interfaces
protected, and declare as
friendsthe clients that are permitted to use them. When the interfaces stabilize, redeclare the components as
public, and delete the declarations of
- In Smalltalk, consider declaring categories of published components. Also consider declaring published message categories to distinguish stable and unstable messages.
- Consider decorating the names of unstable components or interfaces to indicate their “published” status. When the component becomes public, rename it and patch all its clients or deprecate the version with the old name (Deprecate Obsolete Interfaces).
- Clients of published interfaces are aware that they are likely to change.
- Identifying an interface as “published” is purely a matter of convention and discipline.
- Promoting an interface from published to public entails a certain overhead for clients who should upgrade to the new interface.
- Clients can be put in a bind: should they use an unstable published interface, or continue to use the legacy service?
Published Interface is another pattern of the ADAPTOR pattern language [O’C00].
Clients are in a better position to evaluate the risk of using a component if they know its interface is declared to be “published” but not yet public.
When you Present the Right Interface to a legacy component, the new interface may not be stable, so be careful to Distinguish Public from Published Interface. When the new interface stabilizes, or is substituted by a stable replacement component, the interface may become public.
Upgrading an interface to public may entail a change to the way it is accessed. Be sure to Deprecate Obsolete Interfaces.