resources

Using the Strategy pattern with ActionScript 3.0

Feb 11th

Posted by Giorgio Natili in design patterns

No comments

Accordingly to the Gang of four the Strategy pattern intent is to define a family of algorithms an make them interchangeable; the pattern let the algorithm vary independently from the client that use it.
It seems to me a very nice idea because I believe that a good developer have to write his code in an “open way”. What I mean is that if your code it’s full of if statements, conditionals, etc. each change became very difficult to introduce and maintain.
The Strategy pattern can be roughly summarized like in the following UML diagram

Strategy pattern

The context is your application or a component in your application, the strategy may be a class or a method that define which algorithm your system can use, the concrete strategies are the classes that implements the algorithm that suits the needs of your system.
One of the most sample and concrete samples of the application of the Strategy pattern is the calculation of taxes inside an e-commerce application.
Imagine the situation in which your application has to deliver products all around the world and to apply different taxes factor accordingly to the country your customer lives, this means to use a different algorithm (a strategy) for each country.
We need to define a strategy and apply a different tax factor for each country, so model your system with the following classes and interfaces
1.    Calculator: an abstract class that implements the main algorithm
2.    ENTaxCalculator: the class that changes the algorithm in order to apply the right amount of taxes for the English customers
3.    ITTaxCaclulator: the class that changes the algorithm in order to apply the right amount of taxes for the English customers
4.    ITaxCaclulator: the interface that defines the common operations of the strategy and that you can use in your system as the algorithm data type and that it’s implemented by all the strategies

Let’s take a look to the implementation…
First of all in order to avoid the instantiation of your abstract Calculator defines an internal class in the same Calculator.as file and use it in the constructor

package it.mxml.utilities.taxes{
public class Calculator implements ITaxCalculator{
protected var _amount:Number;
protected var _taxesFactor:Number;
public function Calculator(enforcer:AbstractEnforcer){
if (enforcer == null){
throw new Error("AbstractException");
}
}
protected static function getAccess():AbstractEnforcer{
return new AbstractEnforcer();
}
}
internal class AbstractEnforcer{
// Do nothing
}

Now you are ready to define your algorithms extending this class Calculator and changing in the constructor the _taxesFactor value (for brevity I removed from here the methods used for calculation but you can get them in the source code of the sample you find here).
Imagine to have in your application a small basket and a method that calculate the taxes to apply, you can create the instance of the appropriate tax calculator through reflection and show the result

private function doCalculate():void{
var lang:String = Capabilities.language.toUpperCase();
var amount:Number = 0;
for each (var item:Object in selectedItems){
amount += item.price;
}
var calculator:ITaxCalculator;
var ClassDefinition:Class;
try{
ClassDefinition = getDefinitionByName("it.mxml.utilities.taxes." + lang + "TaxCalculator") as Class;
}catch(e:Error){
ClassDefinition = getDefinitionByName("it.mxml.utilities.taxes.DefaulTaxCalculator") as Class;
}
}

In the complete sample application you find here you can get also the output of this method.
At the end of the day we can recap with the following points the Strategy pattern
1.    Define a family of algorithms (with an abstract class) in order to solve a particular issue of your system
2.    Define the single algorithms making them interchangeable (use an interface)
3.    Define a procedure that is able to detect automatically the con text and which strategy to use (the appropriate algorithm)
4.    Keep separate the algorithm definition / implementation and the selection of an algorithm

Obviously this is only a Mickey Mouse sample, but following this building blocks you can define great strategies for your system.

Flex and SVN

Oct 14th

Posted by Giorgio Natili in resources

1 comment

I’m sure that tons of flex developers has already used SVN during the development of their projects but I have seen sometimes great difficulties when during the development of a project different coders need to modify the same file or add a file to a project. In the first situation the way to handle merge is not really intuitive, in the second one most of the times the file is not committed.

For this reason I decided to write some notes on SVN and TortoiseSVN 1.5.4 that has been recently released.

First of all please be sure to use a sane repository layout. There are many ways to lay out your repository. Because branches and tags are ordinary directories, you’ll need to account for them in your repository structure. The Subversion project officially recommends the idea of a “project root”, which represents an anchoring point for a project that contains exactly three subdirectories: /trunk, /branches, and /tags.

“trunk” is supposed to signify the main development line for the project. You could call this “main” or “mainline” or “production” or whatever you like.

“branches” is obviously supposed to be a place to create branches. People use branches for a lot of purposes. You might want to separate your release or maintenance branches from your feature branches or your customer modification branches etc.

“tags” are not treated as special by Subversion either. They are a convention, perhaps enforced by hook script or authoring rules, that indicate you are creating a point in time snapshot. Typically the difference between tags and branches is that the former are not modified once they are created. You might call your tag folders “releases” or “snapshots” or “baselines” or whatever term you prefer.

Be sure to Commit logical change set. When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a “name” for the change. You can mention this revision number in bug databases, or use it as an argument to SVN merge should you want to undo the change or port it to another branch.

Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change twice. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you’ll get a conflict.
Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible. Unfortunately, Subversion is not such a system. Like CVS, Subversion 1.0 does not yet records any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running SVN merge, or from just hand-editing the files.
What does this mean to you, the user? It means that until the day Subversion grows this feature, you’ll have to track merge information yourself. The best place to do this is in the commit log-message.

Let’s take a look to a practical Flex development situation, first of all you have to install Tortoise SVN on your machine and create an empty folder for your project (I’m supposing that you have already started to work on some stuff and that is the time to go under source control and that you are the one that will create the repository).
Right click on the folder and select the import option

01.gif

In the dialog that appears insert the data for the remote repository

02.GIF

Right click again and perform the check out, now your folder is synchronized with the remote repository.
Copy the files you need in the folder and perform a commit, you’ll be prompted to select the files you want to commit

03.PNG

It’s a good habit to remove properties, project, bin-debug, bin-release, etc. in order to perform this task you can deselect the files from this dialog or you can select a specific file, right click and remove it or all the files with the same extension from the synchronization of the repository

04.gif

Now you are able to work quite easily with SVN but remember that

·         in order to rename a file or a folder you must first checkout the file or folder to your machine. Once it’s on your machine, right-click on the file or folder, and select the menu option SVN Rename,

·         in order to delete a file or folder, simply right-click on it, and select the Delete… option from the Tortoise SVN menu

·         to add a file or folder, check out the repo (if you haven’t already done so). move the new file(s) and folder(s) to the location you want them in the repository (for e.g. to add the file newfile.mxml to the mxml/trhunk/newclient/ folder, move newfile.mxml to that folder). Now, with everything in its place, right-click on the file(s) and folder(s) you want to add to the repository, and select the SVN Add… menu option

Basically all the usual operations of an operating system needs to be performed trough the Tortoise SVN contextual menu.

SVN is not a back-up system, is a way to handle versioning and conflict, what happens if you make some changes to a file and another developer make the changes to the same file and both of you make a commit at the end of your working day?
SVN will try to make a merge but sometimes it’s not possible so be careful when you do the commit and use the Check for modifications function from the Tortoise SVN menu option

05.gif

If something goes wrong during the merge you’ll keep your work safe because in the file you are committing SVN will add the change log in the code

<<<<<<< .mine

                var beautiful:int = 5;

=======

                var ugly:int = 5;

>>>>>>> .r10

and in your folder you get a copy of the file with the release name.
I wasn’t a fun of SVN the first time I used but now I am happy to say “It works!”.

Resources
http://electricjellyfish.net/garrett/talks/oscon2004/svn-best-practices/
http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/
http://www.iovene.com/5-svn-best-practices/
http://svnbook.red-bean.com/en/1.4/svn.tour.cycle.html
http://www.changelogic.com/SvnProjectSetup
http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1