Potential Blog

This article describes an interesting design pattern that I utilized in my Potential RPG code. The following describes the pattern in general and how I’ve used it in my code. Has anyone seen this pattern in the wild? Does it have any other common forms or names?

Background: I have a class (let’s call it Subordinate) that has special control methods, which should only be called by a Master class. (Subordinate also has methods for public use.) Consequently, I originally implemented the Subordinate in the same (client-side) package as the Master, using package-protected control methods. Unfortunately, this binds the Subordinate, and everything that needs it, to client-packaged libraries.

Simple Solution: The simple solution is to repackage the Subordinate into its own (non-client-specific) package. Unfortunately, the control methods must become public for the Master (still bound to client-specific logic) to access. The API would have to document, “Please do not call the control methods, unless you’re supposed to.”

The Goal: My goal is to provide a Subordinate that can only be controlled by the Master. One approach is to create a Subordinate interface, and keep its implementation hidden. However, there is no desire to allow any other implementation of the Subordinate (it is best kept final).

Concealed Controller: The crux of this pattern is a Subordinate helper class, called Controller. Controller has access to the (once again) package-protected control methods of the Subordinate. The Controller exposes public access to the control methods. In addition, the only way to obtain a Subordinate is to construct a Controller (which constructs the Subordinate instance internally).

Integration: To use a Subordinate, the Master constructs a Controller and exposes the contained Subordinate publicly (but conceals the Controller for itself). The only access to the Subordinate’s control methods is via the Controller, which is concealed by the Master.

Pseudocode:

package library;
public final class Subordinate
{
    Subordinate() { }
    void control() { ... }
    public void action() { ... }
}
 
package library;
public final class Controller
{
    private final Subordinate sub = new Subordinate();
    public Controller() { }
    public Subordinate get() { return sub; }
    public void control() { sub.control(); }
}
 
package client;
final class Master
{
    private final Controller control = new Controller();
    Master() { activateWhenClientIsReady(); }
    private void activate() { control.control(); }
    public Subordinate get() { return control.get(); }
}

Potential RPG: In my code, the subordinate is a PlayerCharacter class, with activate() and deactivate() control methods, only to be used by the client-side CharacterAgent (master). Many GUI classes integrate with PlayerCharacter, which provides access to the in-world character being controlled by the player. Following this pattern, the CharacterAgent constructs and conceals the Activator (controller), shielding access to the control methods (thus preventing the chaos that would certainly ensue).