In a tree of modules, some modules will need to load assets when selected...and some will themselves need to be loaded.

Creating a class of compiliable modules was primarily a matter of cutting and pasting. I took the BaseModule class:

...and pasted it into a new CompiledBaseModule class, with this edit:

I resisted this crude move at first, fearful that every subclass of BaseModule would similarly have to be pasted over to the CompiledBaseModule line if I wanted a loadable instance of it.

So I latched onto the default plan for all design-pattern impasses: Favor composition over inheritance. Was there a way to internalize loadable spriteness that made it a snap to veer from creating regular modules to creating loadable ones?

There wasn't. A loadable module had to extend Sprite to be compiled, no ifs, ands or buts. And I just knew that in six month's times, I really, really wanted the simplicity of opening up a file, writing "class MyNewMiniApp extends CompiledBaseModule," and compiling away. So I opened up a second line of modules.

I knew that these compiled modules would be loaded by other modules, but I was immediately perplexed by the nature of these other modules:

Obviously, this LoadCompiledModule is not the thing itself, the compiled module not yet loaded. Presumably, it is a stand-in or proxy replaced when the thing itself arrives.

But replaced when, where, how? The advantage of centralizing and standarizing loadables with an interface was that every loadable could be treated uniformly. If the local module or its navigable has to take special measures to replace a stand-in with the real thing, the elegance and utility of this scheme is spoiled.

So the LoadCompiledModule instance has to remain what it is for the outside world, but also become another module entirely...the same, but different...how is this even possible?

The State Pattern: One Object, Multiple Personalities

The first step to solving this puzzler is surprisingly simple. Start by taking the problem literally. The two different states of the module really ARE two different modules. The first one exists in the parent module, and loads the second one. Let's build it:

Now let's build a dummy compiled module:

Once this class is compiled, we can take a second, equally simple step. We have the two modules. We already think of them as two beings inside a single being. So let's make this single, container being, which is the LoadCompiledModule class:

The key variable in this class is innerModule. At first, this variable points to a module created to load another module (unloadedState). When that second module loads, it points towards it, loadedState, as if to say, YOU are the module I now want to be.

So what use is this now-I'm-this, now-I'm-that container, when what's wanted is a personality-shifting module?

Here is where the fun begins, because LoadCompiledDisplay IS actually a module. Check out its superclass, ModuleWrapper:

Do you see what's coming? Basically, this class implements all the methods of IModule, but instead of defining its own methods, it relays all method calls to a inner module.

The innerModule variable is usually named "state," and when the state variable stops pointing at one module (unloadedState) and points at an entirely different module (loadedState), the instance of LoadCompiledModule appears to change its personality because all calls on it are re-routed to the new module:

The first loadable call is relayed to the unloadedState module, the second to the compiled module.

Slick, no?

The State pattern always involves one object that relays calls, and any number of similar-seeming objects (unloadedState, loadedState, canceledState, reloadedState, etc.) that it can relay them to.

State among the Wrappers

Since relaying a functional call or "wrapping" is so central to design patterns, let's take a quick tour of the wrappers.

Strategy. In this pattern, an object consolidates some required functionality in a separate, internal object, then relays function calls to it. It "wraps" itself around this object as if the object were an internal organ.

This kind of wrapper typically exhibits this sytax:

Adapter. An adapter takes a pre-existing object and "wraps" it to make it appear and act like something else.

An example might be a ModuleAdapter that takes an Alert instance and makes it act like a module. Such an adapter might become necessary if comments were made inside the alert's pop-up window, and the user decided to incorporate these comments into the children modules (right after the currently selected module, let's say).

Remember that an Alert is a weakish module, with a loadable and a wakeable, but not an alertable, navigable or controllable. So how will a comment-component Alert inserted into the middle of a series of regular modules (slides, text panels, videos, etc) successfully pretend to be a module, without _loadable, _wakeable or _controllable properties?

Like this:

StateWith adapter, the wrapper and the wrapped are different but forced to seem alike. All the functions in the target interface (IModule) must be defined, but there is no preordained role for the adapted object. Some function calls might be ignored, others might be intercepted and re-directed.

With state, the wrapper and the wrapped are already alike because they implement the same interface, and every single method is directly mapped to the current state.

Decorator. The Decorator pattern takes wrapping to an extreme, wrapping one object multiple times:

As you can see, as with State, the wrapping assumes that the wrapping object and the wrapped object implement the same interface. But in this case, the steady, unique object is not the wrapping object, but the wrapped object. Think of the decorator pattern as the state pattern turned inside out, many times over.

Decorator is useful for piling on incremental modifications to an object's behavior.

Suppose I needed to change the nature of a BaseNavigable. To start, I'd write a NavigableWrapper class like the ModuleWrapper class above. This class would just steps through the INavigable interface and implement its methods in functions like this:

Now suppose that, while the application was running, it suddenly becomes necessary to know when the last child of a module with children had been selected. Perhaps the user has just changed their preference, and now wants a comment box to appear when they've finished a module, or perhaps the database wants to know how long the user lingered there.

Navigables do contain the necessary information (index==numChildren-1) but don't advertise it.

The first step to getting navigable to shout out its terminal position is to subclass Navigable Wrapper and override just one function:

Now, when this information becomes necessary, decorate the module:

After this point, when calls are made on navigable, they are relayed to the original _navigable, with this crucial difference: goto calls are examined, and if the index is the last, a message is dispatched.

The exhilirating thing about Decorators is that there is no logical end to the wrapping process:

Imagine trying to get a comparable level of flexibility by using parameters or subclassing. Now stop imagining! You don't have to enter that hell, because you have the Decorator Pattern in your tool kit.

I've hardly used these wrapper patterns, so I'll stop here...but you must admit they are goofy fun.

Tags: patterns · Flash2 Comments