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
 

Do DDD Repositories and Flex make sense?

ActionScript, Air, Domain-Driven Design, Flex 3 Comments »

I have been thinking about some of the concepts and patterns described in the Domain-Driven Design book and how they could be implemented in a Flex or AIR environment.

One thing that interests me in particular is the use of a Repository as a container for Domain Objects. In short, a Repository is responsible for fetching, persisting and manipulating objects. Its intent is to shield the client from the implementation details of the data storage or the remote services that are used to get and manipulate objects.

However, there seems to be a fundamental problem in creating an ActionScript implementation. Since remote services are handled asynchronously, it is impossible to create a Repository as it is originally described by Eric Evans.

Here's a snippet of a post (by myself) on the DDD list:

Would it be correct to assume that repositories don't make much sense if you are dealing with async remote calls? Or should I say that async data fetching is a problem currently not addressed by DDD? Quoting Eric Evans in the DDD book (p. 157): "The client of a REPOSITORY should be given the illusion that the objects are in memory.". That being said, it is no problem to call a method on a repository and have it return the objects immediately if the objects are in memory. But, if the objects are sent back asynchronously, the whole point of encapsulating that behavior is gone since the client needs to "listen" for a response on the repository. So it knows about the implementation details of the repository.

As a reply, someone offered to try to make the call synchronous by waiting for a result. Although I think that might work, for instance by entering a loop until the result is received, I'm not completely sure as I haven't tried this. Here's my reply:

The problem I see is that the UI will be locked/frozen until the response is received because the code runs in a single thread within the Flash player. That means it won't be possible to create a (animated) loading screen to give the user some visual feedback. This would probably not be a problem with remote calls that return a small amount of data and a fast remote connection, but it certainly will be a (usability) problem if the connection is slow or if we are loading large chunks of data.

Conclusion

So my conclusion at this moment is that implementing Repository in Flex doesn't make much sense since the client still needs to know about some of the technical details of the implementation. Locking the UI would most certainly lead to usability problems (if it would even be possible). On the other hand, a Repository could be perfectly implemented as intended in an AIR application that uses an embedded SQLite database and synchronous calls, but the UI would also be locked.

Thoughts?


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

Flex Builder 3 on Vista: Trial Expired Solved

Flex 4 Comments »

There seem to be some problems with the Flex 3 licenses. Matt Chotin posted some info here and here.

However if you are installing the trial version, the info provided about removing the license.properties file on Windows is not correct if you're on Vista.

The correct path is C:\Users\[USERNAME]\AppData\Local\VirtualStore\ProgramData\
Adobe\Flex\license.properties

After you removed this file, restart Eclipse and you'll be prompted with the license window that states you can continue the 60 day trial.

Have fun!


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

Prana enabled Cairngorm Store

ActionScript, Cairngorm, Flex, Inversion of Control, Prana 11 Comments »

Following up on Douglas McCarroll's modified Cairngorm Store update, I thought I'd take this a step further and add a Prana application context to configure the business delegates and the service locator. This example has support for mock delegates that contain hardcoded local data and is also able to connect to php services using Remote Objects and AMFPHP.

This examples replaces the older Cairngorm Store example that was configured to work with AMF0 and Renaun Erickson's RemoteObjectAMF0. It now uses the latest beta version of AMFPHP and the AMF3 protocol. The services are hosted on this domain so you don't need to setup AMFPHP in order to see this in action.

The code is currently in svn and can be checked out at http://prana.svn.sourceforge.net/viewvc/prana/trunk/samples/PranaCairngormStore/. This sample will also be included in the next release.

Here's a snippet from the readme file:

***

The following files have been added/changed in order to add Prana configuration support for business delegates and service locator:

* Main.mxml: added application context loader and forced compilation of configured classes

package com.adobe.cairngorm.samples.store.business
* BaseBusinessDelegateMock.as: implements IResponderAware, removed responder constructor argument
* CreditCardDelegate.as: extends AbstractRemoteObjectDelegaten, implements ICreditCardDelegate
* CreditCardDelegateMock.as: implements ICreditCardDelegate
* ICreditCardDelegate.as: interface for credit card delegates
* IProductDelegate.as: interface for product delegates
* ProductDelegate.as: extends AbstractRemoteObjectDelegaten, implements IProductDelegate
* ProductDelegateMock.as: implements IProductDelegate

package com.adobe.cairngorm.samples.store.commands
* GetProductsCommand.as: added delegate lookup via ShopModelLocator
* ValidateCreditCardCommand.as: added delegate lookup via ShopModelLocator

package com.adobe.cairngorm.samples.store.model
* ShopModelLocator.as: added creditCardDelegate and productDelegate variables to configure business delegates

***

As a result, we can now lookup the implementation of our business delegates in the commands instead of instantiating new ones. The commands are completely unaware of the implementation of the business delegates. One note though: since we are not creating new delegate instances, we need to set the responder as a property of the delegate before calling its methods.

Actionscript:
  1. var delegate:IProductDelegate = ShopModelLocator.getInstance().productDelegate;
  2. delegate.responder = this;
  3. delegate.getProducts();

Here's how the application is configured in the application context to use the mock delegates:

XML:
  1. <object id="shopModelLocator" class="com.adobe.cairngorm.samples.store.model.ShopModelLocator" factory-method="getInstance">
  2.     <property name="creditCardDelegate">
  3.         <object class="com.adobe.cairngorm.samples.store.business.CreditCardDelegateMock"/>
  4.     </property>
  5.     <property name="productDelegate">
  6.         <object class="com.adobe.cairngorm.samples.store.business.ProductDelegateMock"/>
  7.     </property>
  8. </object>

And here's how the remote object delegates and the service locator are configured:

XML:
  1. <object id="endPoint" class="String">
  2.     <constructor-arg value="http://www.herrodius.com/amfphp/gateway.php"/>
  3. </object>
  4.  
  5. <object id="serviceLocator" class="org.pranaframework.cairngorm.CairngormServiceLocator" factory-method="getInstance">
  6.     <property name="productService">
  7.         <object class="mx.rpc.remoting.mxml.RemoteObject">
  8.             <property name="destination" value="GenericDestination"/>
  9.             <property name="endpoint">
  10.                 <ref>endPoint</ref>
  11.             </property>
  12.             <property name="source" value="com.adobe.cairngorm.samples.store.business.ProductService"/>
  13.         </object>
  14.     </property>
  15.     <property name="creditCardService">
  16.         <object class="mx.rpc.remoting.mxml.RemoteObject">
  17.             <property name="destination" value="GenericDestination"/>
  18.             <property name="endpoint">
  19.                 <ref>endPoint</ref>
  20.             </property>
  21.             <property name="source" value="com.adobe.cairngorm.samples.store.business.CreditCardService"/>
  22.         </object>
  23.     </property>
  24. </object>
  25.  
  26. <object id="shopModelLocator" class="com.adobe.cairngorm.samples.store.model.ShopModelLocator" factory-method="getInstance">
  27.     <property name="creditCardDelegate">
  28.         <object class="com.adobe.cairngorm.samples.store.business.CreditCardDelegate"/>
  29.     </property>
  30.     <property name="productDelegate">
  31.         <object class="com.adobe.cairngorm.samples.store.business.ProductDelegate"/>
  32.     </property>
  33. </object>


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

A Non-English Ubiquitous Language

Domain-Driven Design 3 Comments »

A post on the Domain-Driven Design mailing list got me to reflect on a recent project we did in the domain of accounting. This was a completely new and unknown domain for us as a team and it sure took us a while to grasp the different domain concepts. After some meetings with the (Dutch) clients and as soon as we had enough understanding of the domain, we started developing.

(On a side note: I couldn't help but notice that our client was pretty inpatient whilst teaching us about accounting.)

As a company-department standard, we program all code in English since it feels the most natural given the fact that most (if not all) API's we use are also written in English. However, we quickly faced the following problem: What are the English translations of the different domain concepts we just learned as part of this accounting application? As a result, I spent a fair amount Googling around to find dictionaries with accounting terms and finally wrote down a translation scheme for the domain objects.

Although I'm pretty sure we got the correct translations of the domain objects, it felt awkward at times to work with the API we were creating. In fact, it made developing quite a bit harder because we had to constantly translate terms when we were talking amongst developers and when we were talking with the domain experts/the client at iteration meetings.

On the other hand, mixing Dutch and English code is also pretty awkward and could make the code hard(er) to read. So I'm still kind of undecided about what option to choose. I guess it depends on how transparent the translations of the domain objects are and how easily they are interchangeable.

Does anyone have any experience with this? How are or would you be handling this situation? Do you prefer sticking to English with the added complexity of dealing with domain object translations or do you develop in the language of the domain experts?

Damn you tower.


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