mxml.it

Accordingly to the Gang of four the Abstract Factory pattern intent is to provide an interface for creating families of related or dependent objects without specifying their concrete classes.
This design pattern actually ensures that the patterns automatically get and use the correct object accordingly to the context in which the client is working.
There are many different situations in which this pattern can work, imagine for instance a system in which the drawing and printing method varies accordingly to the resolution supported by the system; the system has to use different drivers in different cases.
At a first glance you may be tempted to use two different switch case for the drawing and printing procedure in which your system reacts in a different way accordingly to the resolution but remember that switches may indicate the need of abstraction in your system and that it can bring your system to a combinatorial explosion (imagine to add new drivers for each different resolution and create and even more complex switch case).
A good way to solve this issue us to create a Factory that creates the appropriate object accordingly to the resolution supported by the system, in this way you avoid the combinatorial explosion I mentioned and you can keep the switches in a single place or even better accordingly to the language you are working on and to your code style you can avoid switches also in the factory.
We have talked since now about two possible families of objects to use, monitor and printer drivers. Give me a chance to introduce you to a more complex system, an e-commerce with a group of families related to the system payments

•    Credit Card
•    OnLine payment
•    Other payment

For each of these families you may have the need to define multiple objects when you system starts

•    Credit Card
o    Visa
o    American Express
o    Master Card
•    OnLine payment
o    Paypal
o    E-check
•    Other payment
o    Wire transfer
o    Check

and add even more objects when the system grows or when new payment methods will be released over the net.
In an e-commerce system you may also have the need to show to the user the appropriate payment system accordingly to his preferences, in order to increase the abstraction of your system you can define multiple Abstract classes and keep the system ignorant on which particular implementation is in use because the factories are the responsible to instantiate them.
Imagine the scenario I described an put it in an UML diagram

The application is composed by a form that contains a submit button and the form fields vary accordingly to the user preferences retrieved by the system.
The CheckOutFactory class is an abstract class that have two concrete implementations able to return to the client the UI needed for each payment (actually the MXML representation of the class). The PaymentContainer is a VBox with a property used to store a reference to the payment form created from the factory that implements an interface that defines two common methods of the payment forms

•    validateFields()
•    submit()

As you know ActionScript 3.0 doesn’t support abstract classes, so the CheckOutFactory simulates the abstraction of the class trough the use of an internal class in its constructor.
Another good way to implement the abstraction is the use of interfaces, this is the reason why I defined a common interface ICheckOut and two other interfaces (IOnlinePayment and ICreditCard) that extend the base interface and that will be implemented in the view of each payment form of the system.
Take a look to the class hierarchy in order to understand where we are and where we are going

The abstraction of the on-line and credit card payments is reached through the interfaces put on the top of the onLinePayment and creditCardPayment packaging, the view and it’s logic has been keep separated through the Model View Presenter pattern used from each payment form.
Each presenter implements a public submit() method, in this way you can call in a centralized fashioned way the submit of each form trough the PaymentContainer property named element, each presenter will have the responsibility to recover the data from the view and each view, due to the fact that implements the ICheckOut interface, validate it’s fields (a good idea is to validate each credit card with a different Validator, this is the reason why you find an instance of the CreditCardValidator class in the  credit card payment forms.
In order to run this sample (view source enabled) I created an XML file that stores the name of some users and the payment preferences, each node has the following structure

<user name = "Giorgio Natili" mode = "OnlinePayment" type = "PayPal" />

In the main application a combo box is populated with this data and each time you change the selection a concrete factory is created and through the factory a new view is added to the PaymentContainer

private function onUserSelection(e:Event):void{
checkOutFactory = CheckOutFactory.getPaymentFacotry(e.target.selectedItem.@mode);
var s:String = e.target.selectedItem.@type;
checkOutModule = checkOutFactory.getUI(s.substr(0, 1).toLocaleLowerCase() + s.substring(1, s.length) + ".view." + s + "View");
paymentContainer.element = checkOutModule;
}

The checkOutFactory and the checkOutMopdule properties data type represents the layer of abstraction I’m searching for
private var checkOutFactory:CheckOutFactory;
private var checkOutModule:ICheckOut;
The method defined as a listener for the click event inside the PaymentContainer uses the methods defined in the ICheckOut interface to complete his task

private function doSubmit():void{
if(_element.validateData()){
_element.submit();
}else{
Alert.show("Invalid data in the form...", "Attention!");
}
}

At the end of the day we have a quite flexible sample, but which are the benefits of this pattern? It would be simpler to have a switch instead of all this code?
The main benefit is that if you have to add the support for another credit card you have to deal only with the logic stored in the MVP triad you need to add a payment form and the system automatically will be able to handle the new form.
The switch could be hard to maintain in a situation with more than 4 payment methods, moreover the abstraction layer that the system has reached give to you the flexibility to put each developer you want on the new payment forms the system needs without having to explain to the developer anything about the system itself.

There are other possible contexts in which the Abstract Factory pattern can be used

•    Handle different operating systems API in a cross platform application
•    Different traits for users of an application
•    Different version of an application
•    Different performance guidelines

At the end of the day we can recap with the following points the Abstract Factory pattern

•    You want to have families or sets of objects for particular clients
•    Families of related objects have to be instantiated
•    You want to coordinate the creation of families of objects
•    You need to isolates the rules of which objects are to be made

Obviously this is only a small sample and more complex implementation are out of the scope of this blog entry, so feel free to open a discussion on this topic.

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

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.

I have heard tons of time the term agile modeling from other developers both in my team and in other teams, with this small article I don’t want to create a reference for the agile modeling process (there are already a lot of resources on-line) but I want to point your attention to some terms and to the procedure I’m used to use during the development of Flex projects.
One of the main issues during the live cycle of a project is the communication between the customer and the development team, what you need is an easy and agile way to define the functionalities of the software that enables the two teams to understand the goals of the project and eventually to change the scope of the features planned for each release.
In order to avoid a situation in which the customer and his team make one all-encompassing set of decision at the beginning of the project you can start to use stories and spread the decision making across the duration of the project.
An user story describe in a very short way a functionality that will be valuable for the customer using a jargon that is not too much technical, moreover a story can be used to track the activity of the development team and to keep track about the conversation between the two main actors of a software development project: the customer team and the development team.
Traditionally the stories are hand written and pointed on a dashboard, so the use of stories is not a way to document a project but a way to represent customer requirements in a very informal way.
In order to write a story that can be useful for the project you have to avoid to put technical statement inside the story, the reason why is that the technology stuffs are related to developers only.
Imagine the simple scenario in which you have to describe the login form of an application, you can put in place these stories

    User can login in the system

    User can recover his password

    User can cancel the login process

    Login form will connect the data base

The first three stories represent a good example, the last one not because this is something that the application need to do but not something that can be clear for the two actors of the development process, move this in the technical specification that will be based on the stories or remove it completely because is quite obvious that some server side interactions are needed in order to run an application.
The key point here is that stories have to be written in a way that customer can evaluate them, project managers can understand them and developers can easily provide information about the time they need to implement the feature.
Sometimes stories are not so simple, imagine if you have to write down stories for a research form in which the user can select multiple and sometimes complex criterion, the functionalities the user can use may be represented with more than a story (remember that stories have to be short), in this scenario you can group them under an epic; an epic can be split into two or more stories (actually I suggest to keep 10 as the maximum number of stories under each epic).
Don’t incur in the mistake to split stories in too much epic and stories until you are able get a story that define all the details, details are a task for the technical specifications that usually (but not always) come after the customer and the development team have complete the stories / epics exercise.
When one of the team need to discuss some details add a note to the story inside the story itself

    User can search for a piece of inventory

        A piece of inventory can be searched accordingly to the price

        A piece of inventory can be searched accordingly to the location
            note: show the location selection

but keep the note as a part of the story itself and if you discuss the story with one of the two teams add relevant information as part of the note.
When you have a story completed you can also add some information about how to test the story, in the real world you can do it writing the tests on the back of the card, otherwise if you use some web application 99% you this option. If you are using another tool you can put the test in a box connected to the story and use the green as the color background.
In order to plan a release with the customer you can put a set of story in a pile (also an Excel file is good enough) in which the stories priority is based on the pile order and use the estimation for the delivery that each developer put on a story in order to understand when the release can be deployed.
If the pile time is not satisfactory for the customer you can split the stories in more than one pile, each pile now represent an iteration of the live cycle of the software.
The time the development team needs to complete a iteration represent the speed of the team and this factor will be the one that a project manager can use to plan new release with the customer without asking a continuous opinion to the development team.
In order to write a good story you can rely to the Bill Wake definition, a good story is
•    Independent
•    Negotiable
•    Valuable to user, customer and developer
•    Estimable
•    Small
•    Testable
Each story has to be as much as possible without any dependency on other stories but if you can’t remove the dependencies you can combine the dependent stories into one larger but independent story or you can find a different way to split the stories.
Stories are negotiable, they are not written contracts or requirements that the software house must implement, stories are short descriptions of functionalities the details of which are negotiated in a conversation between the customer and the development team.
With this approach you can avoid the situation in which a customer is afraid that during the development process everything he said can be used against him.
Actually the stories are a reminder for the developer and the customer to have a conversation then they have to be no more than one sentence or two with some possible notes.
A story has to be valuable for different purposes and so have to be written with a jargon that is understandable for the customer team, the development team and the test users, the best approach is that the customer write the stories but that is not possible the development team have to handle this task carefully.
It is important that the developers are able to estimate the effort to design and develop each story, if the developers or the customers don’t understand the story this is a good starting point for the project manager to write down the agenda of the next meeting.
If the estimation is not possible because there is a lack of knowledge the team can move one or two members on spike, a spike is a brief experiment to learn about an area of the application that is not clear.

Remember always to keep stories small, epics are sometimes difficult to handle but they can be used as well (not too much!).

Stories must be written in a way that make them testable, I mean that a story can be used as a blue print for the unit testing and for the user test, a story is not testable when it comes from a non functional requirement.
Following this building blocks you’ll be able to write good stories and to start to define estimates for each one, the web is full of resources about that so feel free to investigate and learn more on this topic.