Object Oriented Design - Eric Feminella

IResponder and Cairngorm

My original post on Cairngorm and IResponder had accidentally been deleted while updating my moderations queue, and many of you have contacted me stating that the post is no longer available so I will re-iterate what I mentioned in that post.

For some time now I have been entertaining the notion of abstracting IResponder implementations from Command classes into separate, discreet classes which are intended to handle asynchronous service invocation responses. There has been some talk in the Cairngorm community recently regarding Cairngorm Commands and IResponder implementations so I thought I would share my thoughts on the subject.

Typically most Cairngorm Events are handled by an associated Command. The Command handles the Event by updating a model on the ModelLocator, and / or instantiating a Business Delegate to manage invoking a middle-tier service.

At this point one could argue that the Command has finished doing it’s job – handling the Event. Let’s clarify by taking a look at a formal definition of the Command Pattern:

“The Command pattern is a design pattern in which objects are used to represent actions. A command object encapsulates an action and its parameters.”

From this we can deduce (in the context of a Cairngorm Event) that the Event is the “action” and the Command is the object which encapsulates the handling of the Event (action). The actual handling of the Service response could be considered a separate concern which is outside of the direct concern of the Event and Command, thus requiring an additional object to handle the service response.

However for many developers it is (by design) typical to simply have the Command implement IResponder and also handle the response from the service in addition to the actual Event. This makes sense from a convenience perspective, but not necessarily from a design perspective.

What I have been experimenting with is pretty simple and straightforward. It involves having a completely separate object implement IResponder and handle the service response directly.

Consider the following example in which a specific use-case requires an account log in (could the Login Example have replaced Hello World?). The following classes would be required: LoginEvent, LoginCommand, LoginResponder and LoginDelegate. Utilizing a separate class as the responder is very simple and straightforward and would be implemented as follows:

package events

{

import com.adobe.cairngorm.events.CairngormEvent;

import vo.LoginVO;

public class LoginEvent extends CairngormEvent

{

public static const LOGIN_EVENT:String="events.LoginEvent";

public var loginVO:LoginVO;

public function LoginEvent(loginVO:LoginVO)

{

super ( LOGIN_EVENT );

this.loginVO= loginVO;

}

So far nothing different here, the above Event is just like any other CairngormEvent. Now let’s take a look at the Command implementation.

package commands

{

import com.adobe.cairngorm.commands.ICommand;

import com.adobe.cairngorm.events.CairngormEvent;

import events.LoginEvent;

public class LoginCommand implements ICommand

{

public function execute(event:CairngormEvent)

{

var evt:LoginEvent = event as LoginEvent;

var re:IResponder = new LoginResponder();

var delegate:LoginDelegate = new LoginDelegate(re);

delegate.login(evt.loginVO.username, evt.loginVO.password);

}

Based on the above example, the only method which must be implemented is execute(), as defined by ICommand. The implementation of execute() instantiates an instance of LoginResponder and LoginDelegate, the LoginResponder instance is passed to the LoginDelegate as the IResponder instance (as opposed to the traditional approach of the Command being passed).

As can be seen in the following example, the Business Delegate implementation is the same as any other typical Cairngorm Delegate:

package business

{

import com.adobe.cairngorm.business.ServiceLocator;

import mx.rpc.AsyncToken;

import mx.rpc.IResponder;

import mx.rpc.http.HTTPService;

import vo.LoginVO;

public class LoginDelegate

{

private var responder:IResponder;

private var service:HTTPService;

public function LoginDelegate(responder:IResponder)

{

this.responder = responder;

var sl:ServiceLocator = ServiceLocator.getInstance();

service = sl.getHTTPService( Services.LOGIN_SERVICE );

}

public function Login(vo:LoginVO) : void

{

var call:AsyncToken=service.send(vo.username,vo.password);

call.addResponder( responder );

}

public function Logout() : void

{

//...

}

The IResponder implementation would be as follows:

package responders

{

import mx.rpc.IResponder;

public class LoginResponder implements IResponder

{

public function result(data:Object)

{

// result implementation...

}

public function fault(info:Object)

{

// fault implementation...

}

That’s pretty much it. Clean, simple, and yes, more code, however this design supports a clear separation of concerns and promotes encapsulation and code reusability. This example is intentionally cut and dry, however if you consider the many other possible implementations such as utilizing Dependency Injection to inject both delegates and responders, than I believe the benefits become quite clear.

At the end of the day it really comes down to personal preference. For me, I always prefer to have more classes which encapsulate very specific concerns and responsibilities. As long as you have a clear and concise, but most of all, consistent design you usually can’t go wrong.

November 23, 2007 Design Patterns / Object Oriented Design

9 Comments

AS3 StringTokenizer

One useful utility in the java.util package is the StringTokenizer class. I was looking for an ActionScript implementation the other day but was unable to locate one. So after determining the level of effort to write a StringTokenizer in ActionScript was minimal, I decided to roll my own.

The ActionScript StringTokenizer is a convenience class which provides a simple mechanism from which Strings can be extracted into individual tokens based on a specific delimiter.

StringTokenizer provides an IIterator implementation as well as an IEnumeration implementation, thus allowing a StringTokenizer to be implemented as an IIterator or IEnumeration. The interfaces are also provided with the StringTokenizer API.

Ideally a StringTokenizer is to be utilized to tokenize a String into specific tokens and is to be considered read-only. To use StringTokenizer is very simple. The constructor accepts two arguments, both of which are required. The first argument is the source String from which tokens are to be extracted. The second argument is the delimiter from which the tokens are to be based on, as in the following:

var st:StringTokenizer = new StringTokenizer("R.I.A",".");

In addition to the constructor I have provided two static factory methods for creating both the IIterator implementation and IEnumeration implementation. The factory methods require the same arguments as the constructor and are provided as an alternative to the constructor.

var it:IIterator;

it = StringTokenizer.createIterator("R.I.A",".");

// or

var enum:IEnumeration;

enum = StringTokenizer.createEnumeration("R.I.A",".");

All implementations provide operations for determining if elements (tokens) remain as well as operations for retrieving the next element.

A typical StringTokenizer implementations is as follows:

var st:StringTokenizer = new StringTokenizer("R.I.A",".");

while ( st.hasMoreTokens() )

{

trace (st.nextToken() );

}

// outputs

// R

// I

// A

An IIterator implementation would be as follows:

var it:IIterator;

it = StringTokenizer.createIterator("R.I.A",".");

while ( it.hasNext() )

{

trace (it.next() );

}

// outputs

// R

// I

// A

An IEnumeration implementation would be as follows

var enum:IEnumeration;

enum = StringTokenizer.createEnumeration("R.I.A",".");

while ( enum.hasMoreElements() )

{

trace (enum.nextElement() );

}

// outputs

// R

// I

// A

In each use-case the StringTokenizer instance will return the same result as the underlying StringTokenizer implementation (e.g. invoking IIterator.next() results in a call to StringTokenizer.nextToken(), etc).

Source:
StringTokenizer
IEnumeration
IIterator

November 1, 2007 Object Oriented Design

10 Comments

Configurable ContextMenu API update / example

I have received numerous requests for an example which demonstrates how to implement the ConfigurableContextMenu API which I had developed back in February of this year.

In the time since the original post I have re-factored many of the core features, however the goal of the ConfigurableContextMenu API remains the same.

The following is a brief recap from the original post.

The ContextMenu classes in ActionScript 3: ContextMenu, ContextMenuItem, ContextMenuBuiltInItems provide a good base for working with context menus in Flex 2, however they do not provide an intuitive API for developing and working with custom context menus, especially at runtime, so in this regard these classes fall short to some degree.

In order to provide a solution which addresses the issues mentioned above I have developed a ConfigurableContextMenu API which allows developers to dynamically create custom context menus by which items can be added, removed, enabled, disabled, shown, hidden and cloned dynamically at runtime. This API also addresses certain Flash Player restrictions which fail silently in the ContextMenuItem class such as caption collisions and reserved captions restrictions which are simply ignored by Flash Player, leaving the developer clueless (until reading the documentation) as to why the items have not been created.

Below I have provided links to ConfigurableContextMenu resources which include complete documentation, UML class diagrams and basic example Flex application.

example
asdoc
uml diagram

The ConfigurableContextMenu API is published under the MIT license.

October 28, 2007 News / Object Oriented Design / Software Engineering

2 Comments

Enforcing an all static API in ActionScript 3

It is quite common when designing an API or system in Adobe Flex that you will identify certain areas which call for specific classes to contain an all static API.

Typically, all-static classes are utilized as helper, utility and factory classes which provide static methods for performing common utility methods.

A commonly overlooked aspect of such designs is the assumption that an all-static class will not be misused by clients, specifically via instance instantiation, as it is assumed by the designer that an all static class would never be instantiated as there are no instance members available, only static class members. This is a fair assumption. However it is not possible to guarantee this will never occur as ActionScript 3 does not support private constructors (yes, I am back on this subject yet again). Although this is an unfortunate limitation of the language it should not deter you from enforcing such restrictions.

To help facilitate these restrictions in my own designs I have created a very simple, yet effective Abstract class called AbstractStaticBase, which helper and utility classes can extend in order to ensure they are never instantiated.

Classes which contain an all static API can extend AbstractStaticBase in order to ensure they can never be instantiated. This is the only requirement.

AbstractStaticBase is lightweight as it only contains a constructor. The constructor does nothing more than create an Error object and parse the call stack to determine the fully qualified name of the concrete class which has been instantiated, the message property is then set on the Error object and thrown.

Implementation on the clients part is very straightforward as all that is required is to extend AbstractStaticBase.

Consider the following example. CalcUtil is an all static class, to ensure an instance of CalcUtil is never instantiated simply extend AbstractStaticBase as follows:

package com.domain.utils

{

import com.ericfeminella.AbstractStaticBase;

public class CalcUtil extends AbstractStaticBase

{

public static function calculate() : Number

{

// implementation not pertinent to subject

}

// an attempt to instantiate CalcUtil ...

var util:CalcUtil = new CalcUtil ();

// results in the following exception:

// Illegal instantiation attempted

// on class of static type: com.domain.utils::CalcUtil

So if you want to enforce that static classes are never instantiated, simply extend AbstractStaticBase.

September 28, 2007 Code Review / Design Patterns / Object Oriented Design / Software Engineering

Comments Off

Multiton Pattern in ActionScript 3

If you are familiar with the standard GoF Patterns than you more than likely are aware of the Singleton Pattern and the solutions which it provides.

For those of you who are not familiar with the Singleton Pattern it is a Creational Pattern which, when implemented as prescribed ensures only one instance of a class is ever instantiated. This is facilitated via a single global access point from which a singleton instance is to be created and or retrieved.

You may be wondering just what the Singleton Pattern has to do with the Multiton Pattern? And how does the Singleton pattern relate to the Multiton pattern? What are the differences and what are the similarities?

To answer your question the Multiton pattern is a Creational pattern which builds on the concept of the Singleton pattern by adding a mapping of key / value [object] pairs.

Unlike the Singleton Pattern, whereas there is only ever a single instance of an object created, the Multiton pattern ensures that only a single instance of an object is created per key. Therefore there are multiple instances which are managed via the Multiton object. The Multiton pattern provides centralized access of Multiton objects and advocates keyed storage of objects within a system.

Below is a simple example which demonstrates an implementation of the Multiton Pattern in ActionScript 3.0:

package

{

import com.ericfeminella.utils.HashMap;

import com.ericfeminella.utils.IMap;

public final class Multiton

{

private static var instances:IMap = new HashMap();

public function Multiton(access:Private)

{

if (access == null)

{

throw new Error( "Abstract Exception" );

}

public static function getInstance(key:*):Multiton

{

var instance:Multiton=instances.getValue(key);

if ( instance == null )

{

instance = new Multiton( new Private() );

instances.put( key, instance );

}

return instance;

}

public function get id() : *

{

return instances.getKey( this );

}

class Private {}

Here is a breakdown of the above example.

First a new class is created as well as an additional inner class outside of the package which is used to ensure the constructor can only be called from within the class body, in this case the Multiton class.

package

{

public final class Multiton

{

public function Multiton(access:Private)

{

// verify that access is not null

// if it is, then an illegal request

// to instantiate the constructor

// is being attempted

if (access == null)

{

throw new Error( "Abstract Exception" );

}

/**

* inner class restricting constructor access to private

class Private {}

Next a private or protected static var of type HashMap (optionally, a generic Object or Dictionary can be substituted) is defined. The static HashMap instance contains the mappings of keys to objects in the Multiton class. Each key only ever contains a single Multiton object instance, and each Multiton instance can only be accessed by it’s associated key.

package

{

import com.ericfeminella.utils.HashMap;

import com.ericfeminella.utils.IMap;

public final class Multiton

{

// contains key / Multiton instance mappings

private static var instances:IMap = new HashMap();

public function Multiton(access:Private)

{

if (access == null)

{

throw new Error( "Abstract Exception" );

}

/**

* inner class restricting constructor access to private

class Private {}

Lastly, Multiton implementations require a public static method; getInstance(); which is very similar to the static getInstance() as it applies to the Singleton pattern, but with a slightly different signature. The getInstance(); method in a Multiton requires a single parameter which specifies the key from which a new instance is to be assigned and / or retrieved.

Certain Multiton implementations use an object as the key, however it is arguably more intuitive to use a primitive type such as a String to define keys. Regardless, I prefer not to enforce type restraints as the implementation will typically depend on the context in which it is being applied.

package

{

import com.ericfeminella.utils.HashMap;

import com.ericfeminella.utils.IMap;

public final class Multiton

{

private static var instances:IMap = new HashMap();

public function Multiton(access:Private)

{

if (access == null)

{

throw new Error( "Abstract Exception" );

}

// retrieve the appropriate Multiton instance

// if the instance does not currently exist

// one will be instantiated and mapped to

// the specified key. All subsequent client

// requests will return the correct instance

public static function getInstance(key:*):Multiton

{

var instance:Multiton=instances.getValue(key);

if ( instance == null )

{

instance = new Multiton( new Private() );

instances.put( key, instance );

}

return instance;

}

class Private {}

To implement a Multiton instance all that is needed is to invoke the static getInstance(); on the Multiton class object just as one would invoke getInstance() on a singleton class object. However in the Multiton it is assumed that there will be many instances, albeit controlled instances, therefore a key must be specified.

Below is a simple example which demonstrates how to retrieve a specific instance of a Multiton object:

var multiton1:Multiton = Multiton.getInstance( "a" );

trace( multiton1.id ); // a

var multiton2:Multiton = Multiton.getInstance( "a" );

trace( multiton2.id ); // a

var multiton3:Multiton = Multiton.getInstance( "o" );

trace( multiton3.id ); // o

There is not to much documentation on the Multiton Pattern outside of the Ruby community and a Java implementation available on wikipedia, however the Multiton Pattern proves very useful when multiple, controlled object instances are needed.

September 26, 2007 Design Patterns / Object Oriented Design / Software Engineering

2 Comments

AIR Cairngorm (AIR extensions for Cairngorm)

I have developed an open source ActionScript 3 project called “AIR Cairngorm” which is intended to provide a framework for working with the new Adobe AIR services while utilizing the Cairngorm-micro architecture.

When I say AIR Services, I am referring to the SQLite and FileSystem APIs, which are available in Adobe AIR.

AIR Cairngorm provides a framework which developers can employee to build typical Cairngorm applications that utilize these services.

The following is a brief description of the AIR Cairngorm API:

AIRServiceLocator: The AIRServiceLocator is a sub class of Cairngorm ServiceLocator, therefore it inherits the same API as ServiceLocator, and adds an additional API for working with local databases.
view source

SQLService: The SQLService is essentially a wrapper class for the SQLStatement and SQLConnection classes. The SQLService class allows developers to create an mxml implementation just as one would with typical HTTPServices, WebService and so forth in a Cairngorm ServiceLocator.
view source

ISQLResponder: ISQLResponder provides a consistent API from which asynchronous SQLStatement execution results and faults can be handled. ISQLResponder is very similar to IResponder in that it defines both a result and fault handler with a slightly different signature which is specific to a SQLStatement result / fault, (i.e strongly typed parameters).
view source

ISQLStatementResource: ISQLStatementResource is a marker interfaces which is intended to improve code readability by indicating that a class which implements this interface is to provide access to external SQL statements defined in a .properties file.
view source

SQLStatementHelper: SQLStatementHelper is an all static utility class which provides a mechanism for substituting tokens specified in a statement with arbitrary values.
view source

I am also releasing an update to Cairngen (though only a dot release) which supports the AIR Cairngorm API. Cairngen will now provide targets for generating business delegates which utilize the AIR Cairngorm services.

I suspect Adobe will release an updated version of Cairngorm which supports integration with AIR applications. AIR Cairngorm provides an interim solution which developers can use under the terms specified in the License.

I plan to update AIR Cairngorm to support the AIR File system API within the next week or so.

Below I have provided downloads for the source, binary, AIR Cairngen and usage example:
source
example
air-cairngen
air-cairngorm

July 16, 2007 Object Oriented Design / Software Engineering

19 Comments