Combining Factory and Strategy patterns

Design Patterns, Inversion of Control, Prana 5 Comments »

We often run into a scenario at work where we have to create an object from xml. More specifically we are parsing xml files with exercise (or assessment item) data to a concrete exercise type like a MultipleChoice, FillGaps, HotSpot, etc. The thing is that we are supporting several xml dialects for the same type of exercise and we end up with a lot of parsers. On top of that we also need to be able to decide on a per project basis what xml dialects are supported (a customer may only be allowed to use dialext X for exercise Y). In the next lines I will try to explain the way we manage and configure the objects that are involved in this process.

The basic idea is that we create a factory, let's call it ExerciseFactory, and define a createFromXML() method on it that takes an xml object as its input and "creates" a concrete exercise as its output. The factory is basically an xml parser. It works as follows:

Actionscript:
  1. var exerciseFactory:ExerciseFactory = new ExerciseFactory();
  2. var exercise:Exercise = exerciseFactory.createFromXML(xml);

Exercise is the base class for all exercise types like MultipleChoice, FillGaps, etc. The given xml object will be in a format that corresponds to such a concrete type. The factory however needs to know what the given xml is and what concrete exercise type it should return. The easiest way to handle these different xml dialects is with a switch on some property of the xml data. This results in code similar to this (in the ExerciseFactory class):

Actionscript:
  1. public function createFromXML(xml:XML):Exercise {
  2.   var result:Exercise;
  3.   switch (xml.someProperty) {
  4.     case multiplechoice-dialect-a:
  5.       // parse type MultipleChoice with dialect a
  6.       break;
  7.     case multiplechoice-dialect-b:
  8.       // parse type MultipleChoice with dialect b
  9.       break;
  10.     case multiplechoice-dialect-c:
  11.       // parse type MultipleChoice with dialect c
  12.       break;
  13.     case fillgaps-dialect-a:
  14.       // parse type FillGaps with dialect a
  15.       break;
  16.     case fillgaps-dialect-b:
  17.       // parse type FillGaps with dialect b
  18.       break;
  19.     default:
  20.       throw new Error("Cannot create exercise for the given xml object.");
  21.   }
  22.   return result;
  23. }

Although this works, it is certainly bad design since it is code that is hard to maintain and manage. If we need to add or remove some parsers, we have to modify this code which is buried deep inside some package hierarchy. We can't change this behavior at runtime since the parsers are hardcoded into the switch/case.

We could solve this with a mapping configured inside the ExerciseFactory. As its key, it contains the value of the property in the xml data we did the switch on. As its value it contains the class or an instance of the parser. This results in something like the following:

Actionscript:
  1. public function ExerciseFactory() {
  2.   this.map = {};
  3.   this.map[multiplechoice-dialect-a] = new MultipleChoiceDialectAParser();
  4.   this.map[multiplechoice-dialect-b] = new MultipleChoiceDialectBParser();
  5.   this.map[fillgaps-dialect-a] = new FillGapsDialectAParser();
  6. }
  7.  
  8. public function createFromXML(xml:XML):Exercise {
  9.   var parser:ExerciseParser = this.map[xml.someProperty];
  10.   return parser.parse(xml);
  11. }

Ok this seems better, but we can't configure the parsers externally since they are coded in the contructor. Let's externalize this by passing in the map to the constructor and additionally create a method for adding a parser.

Actionscript:
  1. public function ExerciseFactory(map:Object) {
  2.   this.map = map;
  3. }
  4.  
  5. public function addParser(key:String, parser:ExerciseParser):void {
  6.   this.map[key] = parser;
  7. }
  8.  
  9. public function createFromXML(xml:XML):Exercise {
  10.   var parser:ExerciseParser = this.map[xml.someProperty];
  11.   return parser.parse(xml);
  12. }

This is a neat implementation. We're setting a behavior or strategy for the parser in the factory at runtime, based on some configuration. But it has a drawback: the name of the property (xml.someProperty) in the xml data we use as a key in our map always needs to be the same for the different xml dialects. Unfortunately, we can't really control this because a new dialect might be used one day that does not contain the property.

To solve this, let's add another method to our parsers: canCreate(xml:XML):Boolean. As a parameter, it takes the xml data and then checks if it can parse the data by looking into the xml structure. Finally, it returns a boolean indicating whether or not the xml can be parsed. This way, the parser decides for itself what portions of the xml data to check instead of just the one property mentioned earlier.

To force this behavior upon the parsers, we can create an interface, IExerciseParser, and then let every parser implement it:

Actionscript:
  1. public interface IExerciseParser {
  2.   function canParse(xml:XML):Boolean;
  3.   function parse(xml:XML):Exercise;
  4. }
  5.  
  6. public class MultipleChoiceDialectAParser implements IExerciseParser {
  7.   public function canParse(xml:XML):Boolean {
  8.     // check the xml structure
  9.   }
  10.   function parse(xml:XML):Exercise {
  11.     // parse the xml to a MultipleChoice
  12.   }
  13. }
  14.  
  15. public class MultipleChoiceDialectBParser implements IExerciseParser {
  16.   public function canParse(xml:XML):Boolean {
  17.     // check the xml structure
  18.   }
  19.   function parse(xml:XML):Exercise {
  20.     // parse the xml to a MultipleChoice
  21.   }
  22. }
  23.  
  24. public class FillGapsDialectAParser implements IExerciseParser {
  25.   public function canParse(xml:XML):Boolean {
  26.     // check the xml structure
  27.   }
  28.   function parse(xml:XML):Exercise {
  29.     // parse the xml to a FillGaps
  30.   }
  31. }

We can now change the implementation of the ExerciseParser. We will remove the map because we will no longer be checking on a key to get a parser, but the parsers will check for themselves.

Actionscript:
  1. public function ExerciseFactory(parsers:Array) {
  2.   this.parsers = parsers;
  3. }
  4.  
  5. public function addParser(parser:IExerciseParser):void {
  6.   this.parsers.push(parser);
  7. }
  8.  
  9. public function createFromXML(xml:XML):Exercise {
  10.   var result:Exercise;
  11.   for (var i:int = 0; i<this.parsers.length; i++) {
  12.     var parser:IExerciseParser = this.parsers[i];
  13.     if (parser.canParse(xml)) {
  14.       result = parser.parse(xml);
  15.       break;
  16.     }
  17.   }
  18.   if (!result) {
  19.     throw new Error("Cannot create exercise for the given xml object.");
  20.   }
  21.   return result;
  22. }

... and configure our exercise factory before using it:

Actionscript:
  1. var exerciseFactory:ExerciseFactory = new ExerciseFactory();
  2. exerciseFactory.addParser(new MultipleChoiceDialectAParser());
  3. exerciseFactory.addParser(new MultipleChoiceDialectBParser());
  4. exerciseFactory.addParser(new FillGapsDialectAParser());

What we have achieved now is that we can add new parsers that support new xml dialects without the need to alter the code of the ExerciseFactory. All we need to is create a new parser, let it implement the IExerciseParser interface and it to the ExerciseFactory.

Additionaly, configuring the ExerciseFactory in a Prana application context is a piece of cake:

XML:
  1. <objects>
  2.   <object id="exerciseFactory" class="ExerciseFactory">
  3.     <constructor-arg>
  4.       <array>
  5.         <object class="MultipleChoiceDialectAParser"/>
  6.         <object class="MultipleChoiceDialectBParser"/>
  7.         <object class="FillGapsDialectAParser"/>
  8.       </array>
  9.     </constructor-arg>
  10.   </object>
  11. </objects>

Hope you enjoyed this. Don't hesitate to leave questions or comments. Have fun coding!


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 

Domain-Driven Design, Thoughts?

ActionScript, Book reviews, Design Patterns, Flex 8 Comments »

Domain-Driven DesignI'm currently reading Eric Evans' book "Domain-Driven Design: Tackling Complexity in the Heart of Software". Domain-Driven Design, or DDD, is about seeing the role of the model as the crucial part of a software project, about creating domain logic that is based on the model, about creating an ubiquitous language that is to be used by all team members (even non-technical) and much more.

This is exactly how I have been thinking about application design for quite some time now, especially since I moved from developing web applications that primarily dealt with CRUD operations to Flash platform development. The Flex projects I have been working on for the last years all have pretty complex domain models and they require a whole different approach and discipline in thinking about application architecture.

This might seem very obvious, but in a highly visual environment like Flex/Flash it is very tempting to focus on the User Interface first and hack together a "domain model" that really has a less important role. You end up with a weak model that is hard to expand, debug and Unit Test and in the end it makes you lose a lot of time.

This also gets me to think about the popular architectural Flex frameworks out there. In my opinion they break the principles of DDD by either providing base model classes that your domain model should be based on (Proxies in PureMVC) or by promoting the use of Value Objects as a domain model (Cairngorm).

We use Cairngorm in our projects but we (almost) never work directly on the Value Objects (or should I say Data Transfer Objects). Before an entity or a VO is sent or received, it is pulled through an Assembler that translates it both ways. It is obviously more work to create this mapping mechanism, but my experience is that it really pays off in the end. For instance, if you use remoting and are sending out or receiving domain objects, you have to make all your properties public or you must create getter/setters for them, you can't properly use constructors since the AMF mapping relies on properties, you have to expose your arrays or collections in order to map them, ... This makes the domain model more fragile, something you want to avoid as much as possible.

Another thing that is worth mentioning is the use of Repositories in DDD. Repository is very similar to the ModelLocator known in Cairngorm, but instead of having a singleton model, a Repository is created for a single domain entity. The Repository contains query methods to retrieve objects based on certain criteria. It also promotes not having too much associations between objects because those are hard to maintain and provides association lookup methods.

I'll try to post an in depth review when I finished the book.

In the meantime, I wonder how many Flex projects are actually dealing with complex domain models and I'm even more interested in what frameworks are being used, if any. If you have any experiences or thoughts to share, please feel free to comment.


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 

Typesafe Enum Pattern in AS3

ActionScript, Design Patterns, Flash, Flex 4 Comments »

I was trying to create a typesafe enum today to hold a Debit and Credit value and realized it could not that easily be done in AS3. In AS2 or in Java (prior to Java 5 when there was no enum construct) you could do the trick by making the constructor of the enum private and instantiate the values as static constants. (See this blog post for an AS2 example.)

Read the rest of this entry »


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 

Tony Hillerson on Cairngorm Business Delegates with Prana

ActionScript, Cairngorm, Design Patterns, Flex, Prana 2 Comments »

In case you haven't read this, Tony Hillerson has posted an article on configuring a Business Delegate Factory for Cairngorm with Prana. This allows you to quickly switch between different implementations for testing or production purposes.

Read it at http://thillerson.blogspot.com/2007/10/delegate-factories-with-prana.html

It's good to see that the community is picking up Prana and benefits from it. Keep on supporting the project guys, thx!


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 

Adding a check for ICommand to addCommand() in Cairngorm

ActionScript, Cairngorm, Design Patterns, Flex, Prana 2 Comments »

Once in a while, when adding event/command mappings in Cairngorm's frontcontroller, I mistakingly add an event instead of a command class to the addCommand() method. Here's an example:

Actionscript:
  1. addCommand(UserEvent.LOAD, LoadUserEvent);

while it really should be:

Actionscript:
  1. addCommand(UserEvent.LOAD, LoadUserCommand);

This is just a mistake when typing fast and with code completion but it can take a while until you find out what you did wrong. To prevent this, I decided to override addCommand() in Prana's CairngormFrontController and add in a check to see if the commandRef argument actually is an implementation of ICommand.

You can checkout this code from Prana's SVN if you like, or you can build a custom version of Cairngorm with the following code:

Actionscript:
  1. public function addCommand(commandName:String, commandRef:Class, useWeakReference:Boolean = true ):void {
  2.   if (commands[ commandName ] != null )
  3.     throw new CairngormError( CairngormMessageCodes.COMMAND_ALREADY_REGISTERED, commandName );
  4.  
  5.   if (null == commandRef) {
  6.     throw new Error("The commandRef argument cannot be null");
  7.   }
  8.   else {
  9.     var classDescription:XML = describeType(commandRef) as XML;
  10.     var implementsICommand:Boolean = (classDescription.factory.implementsInterface.(@type == getQualifiedClassName(ICommand)).length() != 0);
  11.     if (!implementsICommand)
  12.       throw new Error("The commandRef argument '" + commandRef + "' should implement the ICommand interface");
  13.   }
  14.  
  15.   commands[ commandName ] = commandRef;
  16.   CairngormEventDispatcher.getInstance().addEventListener( commandName, executeCommand, false, 0, useWeakReference );
  17. }

This should save you some time in the future.

On a side note, I have been working on an alternative approach to chaining events/commands in Cairngorm. The code is already in Prana's SVN but I haven't had the time to blog about this. Check it out if you're interested and mail me if you want a code example. In the meantime, I'll work a blogpost with an example on how to use it and will publish this by the end of the week.

Happy coding!


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Login