This article is one in a series about HTML5 Application Design
Working with teams on HTML5 applications, you find many people carrying many misconceptions about the basic building blocks of an application.
We will be exploring how to build Strong Types in your framework. Those interested in further reading on Best Practices should read Addy Osmani’s book “Learning JavaScript Design Patterns“.
Traditional Approaches
Singletons
By far the most common ‘accidental’ pattern, this consists of simply creating a structured definition of an object then making sure that the instance is maintained global to the closure context. The advantage being calling an object will lazy-create an instance of one does not exist, then track that instance for the lifetime of the parent object scope. The problem with this approach is that in order to maintain the instance of the internal reference, such as a Delete action, you will need to decorate the surface api returned in the instance itself. But, as Singleton implies, this pattern was designed assuming that the Engineer doesn’t have to worry about instance life-cycle management. A useful tool for Utility Classes or Shared Behaviors, but it doesn’t help us much for Domain Driven Design.Regular/Revealing Modules
When one is concerned with the encapsulation problems exposed in the Singleton approach, with a tinge of need for instance tracking, the Revealing Module pattern fills in parts of the gap. With this approach we are still dealing with a Facade on functionality and behavior, but this is not a good example of something that would represent instances of real concepts. It allows us to build up private members, hide functionality from the surface api and at least track the instance of the module outside of the instance closure. But, this still is a bit too limited to support any real domain design. Extension/Inheritance is supported by ‘patching’. Polymorphism really is a pattern of decorating the existing implementations with new code that has no structural relationship to the base implementations. So, in short, this pattern really is a beefed up Helper class.Enter the Strong Baseclass
To resolve some of the issues encountered with rich business domains, I recommend using the Class packaged in the MooTools library.You can use the MooTools CoreBuilder to pull only the Class definition itself, without any other pieces of the framework
With the Class Package, you can use real Type Inheritance, Extension and have a delayed constructor for all of your objects. Additionally, you even can use the Javascript instanceof operator to refine behavior based on type taxonomy.
Let’s jump into an example to show you how powerful this can be for Javascript design patterns.
Example: Building a View Tier
Create a View Baseclass
Define a class definition that will represent a “View” in the Application.
Extension with Refined Types
Next, let’s create a few different types of View’s that extend the base functionality of the parent View type.
Orchestrate Instances
The biggest difference from the Revealing Module Pattern and the strong baseclass is that our ‘IntroductionView’ and ‘WizardView’ are structural definitions of a type, not instances themselves. This is valuable in that we can control the Creational Patterns, Track instance life-cycles and use the well known Design Patterns native to the Object-Oriented legacy
Using Instances
Using the strong baseclass, we can differentiate between concrete types and take advantage of polymorphism.
Manage Memory Usage
Since we control the instances of our views, we can cleanly utilize the Javascript Delete operator