Contents

A public interface object delegates some of its responsibility to a private instance in the same scope.

Structural Pattern: The private and public instances are tightly coupled. They share data with each other only within the scope where they are defined.

Usage: Details and complexities of the underlying object must be hidden. By exposing a very limited set of methods, the public interface offers little opportunity to modify and break its corresponding private counterpart.

Example: User wants to be able to interact with "program" objects on a calendar. The program can be then modified by the user.

The application handles modification of program objects through a ProgramProxy, by calling setPhases, setCampaigns. The client of the API may call buildHTML to generate new HTML for the program or toJSON to get a JSON representation of it.

The popular alternative to this approach is MVC with libraries such as Backbone, YUI app framework, Meteor, or Angular, most of which use Handlebars.

Prefabricated solutions can work, in the general sense. But they often entail creating a much larger codebase with less specificity to the design of the application. These frameworks, while commonly used, add the complexity of adapting your application's logic to their framework (shoehorning). Being so generalized, they generally fail to address specific problem effectively.

Such interdependent, large libraries introduce inevitable bugs and memory leaks that can be extremely difficult to track down, harder yet to patch, and with patches might never get merged into the existing codebase.

Design patterns are not frameworks. A design pattern is any reusable solution to a type problem in a given context. Any elegant solution therefore depends on the problem at hand (and not the other way around). Although this architectural pattern depicts the architecture, it is not an architecture.

It thus follows that the PrivateProxy presented can be a solution for some sorts of problems, but cannot be the Answer to Solve our Problems, in the general sense.

Because each ProgramProxy instance has a corresponding Program instance with the same id, any ProgramProxy or can access its Program instance counterpart from within any of its instance methods, and vice versa.

This shared instance access is possible because both Program and ProgramProxy instances being stored in a corresponding object for, keyed by id. Ideally, this would be implemented in a WeakMap.