Eric Feminella

I have been posting updates of my utils package lately but haven’t had the time to walk through how to use the API’s in detail other than the provided ASDoc.

One of the really useful API’s in the utils package is the Iterator implementation. The Iterator API provides a standard implementation of the Iterator pattern and is useful for traversing an object, array or collection of objects. The Iterator API provides an Array Iterator, ArrayCollection Iterator and an Object Iterator. You can use them individually as needed but one of the coolest features is the Iterator Factory. The Iterator Factory handles iterator instantiation and allows a single iterator instance, typed as an IIterator interface, to use any of the iterators, via the Iterator Factory.

You can click here to view an example of how to use the Iterator Factory.



Most developers who are relatively new to Patterns immediately think “MVC” when they here the term “Design Patterns”, and this makes perfect sense considering most of developers have either been using MVC for a long time or have construed their own variations of it’s implementation. What ever the case it is important to understand the basic concepts and implementation of Model-View-Controller, especially as it pertains to Rich Internet Applications, or more specifically, Flex Applications.

Model-View-Controller falls under the category of what is known as a compound pattern, that is, a combination of several different Design Patterns to create a named solution. The patterns that make up MVC are typically the Observer Pattern (Model), Strategy Pattern (View and Controller) and the Composite Pattern (View). MVC originated in the Smalltalk-80 language back in the 80’s and it has since been implemented by just about every programming language that requires a user interface, so it is a perfect solution for building Flex Applications.

Implement MVC in Flex Applications is very simple as Event dispatching and data binding can be utilized to simplify invocation between members of the MVC triad. This allows developers to remove the somewhat awkward Observer pattern which is dependent on passing references of each member throughout the MVC triad.

The MVC paradigm is a way of breaking an application, or more commonly, just a piece of an application’s interface, into three parts: the model, the view, and the controller. Each member is intentionally segregated and represented by an object that is responsible for handling a specific task within the application.

Model: The model is used to manage information and notify observers when that information changes (typically via data binding).

View: The view is responsible for rendering the model to the user. This is usually rendered as a visual display but a view may also be a sound, a controller vibrating or anything that needs to be conveyed to the user.

Controller: The controller accepts input from the user (via Event Dispatching) and instructs the model and view to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response. For example, if the user clicks the mouse button, the controller is responsible for determining how the application should respond.

To view a simple example which demonstrates implementing MVC in Flex 2 / ActionScript 3.0 click here.

As a software developer I spend a great deal of my time implementing various design patterns to solve common problems. As I explore a particular problem domain I can easily identify which pattern or patterns can be applied in order to create a viable solution.There are currently 23 common software design patterns around today. These 23 patterns can be organized into three separate categories: Creational, Structural and Behavioral.

Many of these standard patterns are commonly used by developers in all areas of programming and many apply to RIA development. The greatest thing about design patterns is that they are typically not much more than an efficient, structured way of doing things that most of us have already been doing for a long time. Design Patterns allow us to simplify common design problems into standard, common named solutions. By implementing common design patterns and best practices we can keep our applications consistant without re-inventing the wheel every time. They allow us to solve the same problems over and over again in the same way. Design patterns also allow us to write code that is common amongst other developers. This is helpful as it allows other developers who are familiar with these patterns to easily and intuitively work with our code, and vice-versa.

Personally, when designing an application I prefer to use the Adobe Cairngorm micro-architecture, whereas there are various patterns combined to create an architectural framework which can be implemented to provide a common solution. An Architectural framework is a framework that does not provide additional services or API’s (such as the Flex framework) but instead provides a consistent, generic architectural framework that an application can be built upon.

Over the course of the next few weeks I will be posting examples of various pattern implementations in ActionScript 3 and how these patterns can be utilized in order create solutions to common problems.

Many times when developing you will find that your application calls for a single instance of a class to manage a specific service across the system. For example, let’s say that your application needs to have one single instance of a class that manages all events within the system. Or another scenario could be where the application calls for a single instance of a class to manage all WSDL calls across the system. In order to support the required functionality for the application you would need to create a class that implements what is known as the Singleton design pattern.

The Singleton pattern is implemented by creating a class that has a static public method which instantiates a new instance of the object if one does not exist. If an instance already exists, it simply returns a reference to that object which is a static property of the class, typically named ‘instance’. A best practice naming convention for this method is ‘getInstance();’. To make sure that the object cannot be instantiated in any other way, the constructor is made either private or protected. A Singleton is also considered to be an anti-pattern to some extent as it can be used as a euphemism for a global variable. However, in Object Oriented Programming it is an extreamly useful tool when used correctly.

As I mentioned earlier, the constructor for a Singleton is made either private or protected to restrict it’s access from being instantiated. Since constructors can only be declared as public in ActionScript 3 this is not allowed. A common solution to this is to simply add a inner class within the same file as the class definition and pass an instance of the private class as an argument to the constructor. This way only the getInstance(); method has access to the private class. The only problem with this approach is that the constructor can be called from anywhere within the application with a null value passed in as the argument to the constructor. My solution to this is simple, check that the parameter passed to the constructor is not null. This is how a true Singleton implementation is achieved. The only time that this will not work is if the singleton class is a sub class and the constructor needs to make a call to super. The reason that this will not work is that a call to a super classes constructor must be executed in the very first line of code, therefore a parameter value can not be validated.

Below I have added a simple example demonstrating how to implement the Singleton pattern in ActionScript 3.0: