Skip to main content
Engineering LibreTexts

7.10: Distinguish Public from Published Interface

  • Page ID
    32910
  • Also Known As: Published Interface [O’C00].

    Intent Facilitate parallel development by distinguishing unstable “published interfaces” from stable “public interfaces”.

    Problem

    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.

    Solution

    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.

    Hints

    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 public.
    • In C++, consider declaring components with published interfaces private or protected, and declare as friends the clients that are permitted to use them. When the interfaces stabilize, redeclare the components as public, and delete the declarations of friends.
    • 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).

    Tradeoffs

    Pros

    • Clients of published interfaces are aware that they are likely to change.

    Cons

    • 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.

    Difficulties

    • Clients can be put in a bind: should they use an unstable published interface, or continue to use the legacy service?

    Known Uses

    Published Interface is another pattern of the ADAPTOR pattern language [O’C00].

    Rationale

    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.

    Related Patterns

    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.

    • Was this article helpful?