Often I come across what I like to call “Misplaced Code”, that is, code which should be refactored to a specific, independent concern rather than mistakenly being defined in an incorrect context.

For instance, consider the following example to get a better idea of what I mean:

Taking the above example into a broader context, it is quite common to see code such as this scattered throughout a codebase; particularly in the context of view concerns. At best this could become hard to maintain and, at worst, it will result in unexpected bugs down the road. In most cases (as in the above example) the actual code itself is not necessarily bad, however it is the context in which it is placed which is what I would like to highlight as it will almost certainly cause technical debt to some extent.

Considering the above example, should code such as this become redundantly implemented throughout a codebase it is quite easy to see how it can become a maintenance issue as, something as simple as a change to a hostname would require multiple refactorings. A much more appropriate solution would be to encapsulate this logic within a specific class whose purpose is to provide a facility from which this information can be determined. In this manner unnecessary redundancy would be eliminated (as well as risk) and valuable development time would be regained as the code would need only be tested and written once – in one place.

So again, using the above example, this could be refactored to a specific API and client code would leverage the API as in the following:

This may appear quite straightforward, however, I have seen examples (this one in particular) in numerous projects over the years and it is worth pointing out. Always take the context to which code is placed into consideration and you will reap the maintenance benefits in the long run.

A week or so prior to MAX, the Cairngorm committee had a rather interesting discussion, during which Alex outlined what the team at Adobe Technical Services had been considering for Cairngorm 3. The meeting was focused on providing everyone with an overview of the collective ideas which Adobe had been gathering internally for some time now, and to also inquire feedback prior to the public announcement of Cairngorm 3.

Prior to the meeting I had anticipated the discussion would be based around a few new patterns and best practices which are currently being advocated, and possibly some additional libraries which help to address recent challenges in RIA development. However, what we discussed was actually quite different – in a good way.

As you are probably aware by now, Cairngorm 3 is focused around tried and tested best practices and guidelines which aid Flex developers in providing solutions to their day to day RIA challenges. These guidelines are primarily based upon that which has been realized by Adobe Technical Services, and also from the Flex community at large. Teams can leverage these guidelines where applicable to help deliver successful RIAs using frameworks of their choosing. While there may be specific frameworks and libraries recommended in Cairngorm 3, these are just that – recommendations. There is generally a framework agnostic approach which I must emphasize is highly preferable to that of suggesting one framework over another. This is precisely what I think is needed in the Flex community, for there is rarely a one size fits all approach to software architecture, especially in terms of specific framework implementations. This is a pretty easy concept to comprehend, as, what works for one team, in one context, may not always be appropriate for another team, or in another context.

Cairngorm 3 is a step forward towards what (IMHO) should be a general consensus in the Flex community at large; there are many existing frameworks out there which help address specific problems, with each providing unique qualities and solutions in their own right. This is the kind of thought leadership which helps a community progress and grow; it should be encouraged, as allowing for the shared knowledge of fundamental design principles and guidelines is something which provides value to all Flex developers, regardless of which framework they happen to prefer.

If there is one suggestion I would propose, it would be to have an entirely new name for these collections of best practices, guidelines and general Flex specific solutions. Personally, I would like to see the name Cairngorm (which, after all these years, I still pronounce as Care-in-gorm) refer to the original MVC framework, i.e. the framework implementation itself, as keeping the name the same while undergoing a different direction is bound to cause confusion to some extent. Whatever the new name would be is insignificant as long as the original name of Cairngorm applied to that of the actual framework implementation. This would perhaps be more intuitive as it would allow for the name Cairngorm to be used to describe a concrete framework as a potential solution, just as one could describe other frameworks; e.g. Spring ActionScript, Mate, Swiz, Parsley, Penne, Model-Glue, PureMVC, Flicc etc.

Most importantly, however, is the prospect of choice, as choice is always a good thing. Moreover, an initiative being lead by Adobe in this area sends a very good message to the Flex community as a whole. I happen to leverage a number of different frameworks and patterns which address different problems. As new problems arise, I employ new solutions where existing solutions may not suffice, or develop custom solutions where none are currently available; never blindly choosing one solution over another. However, in every case, there are typically some basic, fundamental guidelines which hold true and can be followed to help drive a design in the right direction. Regular readers of this blog have probably noticed that the basis of the majority of my posts are heavily rooted within these fundamental design principles, as it is from these fundamental design principles and guidelines that developers can utilize the frameworks which work best for them in order to and meet their specific challenges.

Essentially, Software Architecture is all about managing complexity, and there are many fundamental patterns and guidelines which can help developers mange this complexity. The specific framework implementations are of less concern, for it is the understanding of these patterns and principles – and more importantly, when to apply them, which will ultimately drive the decisions to leverage a one framework over another. In my experience, I have found that the only constant in software architecture is that a pragmatic approach should be taken whenever possible, whereby context is always key, and simplicity is favored as much as possible. Cairngorm 3, I feel, is a nice illustration of this principle.

One of the many welcome additions to the Flex 3.4 SDK is the inclusion of the Vector class. Vectors in particular are especially welcome as they provide compile time type safety over what would otherwise not be available when implementing custom solutions, such as a typed collection.

Essentially, Vectors are just typed Arrays. And while not as robust or powerful, Vectors are similar to Generics in C# and Java. When it is known at design time that a collection will only ever need to work with a single type, Vectors can be utilized to provide type safety and also to allow for significant performance gains over using other collection types in Flex.

I recently wanted to convert quite a few typed Array implementations to Vectors, however, the Arrays were being traversed with an Iterator. In order to reduce the amount of client code which needed to be refactored I simply implemented a Vector specific Iterator implementation.

If you are familiar with Iterator Pattern in general, and the Iterator interface in particular, then usage will prove to be very straight forward. You can use the Vector Iterator to perform standard iterations over a Vector. Below is an example of a typical client implementation:

Using an Iterator with a Vector ensures only a linear search can be performed, which proves useful with Vectors as they are dense Arrays. However, one consideration that must be made when using an Iterator with a Vector is that you loose type safety when accessing items in the Vector via iterator.next(). It is because of this I would suggest only using Iterator’s with Vectors to support backwards compatibility when refactoring existing Arrays which are being used with existing Iterators.

The VectorIterator and it’s associated test are available below:
VectorIterator
VectorIteratorTest

It is quite common to find a significant amount of code redundancy in Flex applications built on Cairngorm. This is by no means a fault of the framework itself, actually quite the contrary as Cairngorm is designed with simplicity in mind; opting to appropriately take a less-is-more approach in favor of providing a more prescriptive framework which only defines the implementation classes necessary to facilitate the “plumbing” behind the framework. Everything else is really just an interface.

With this amount of flexibility comes additional responsibility in that developers must decide what the most appropriate design is based on their applications specific context. Moreover, as with any design there is never a truly one size fits all approach which can be applied to any problem domain; there are really only common patterns and conventions which can be applied across domains and applications. This IMHO is what had allowed the framework to be a success and it is important to understand that this simplicity also requires developers to give their designs the same attention one would to any Object Oriented design.

However over the years I have found a significant amount of redundancy found in Flex applications built on Cairngorm. This appears to be (more often than not) the result of developers implementing Cairngorm examples verbatim in real world applications, and in doing so failing to define proper abstractions for commonly associated concerns and related responsibilities. The most common example of this is the typical implementation of Commands, Responders BusinessDelegates and PresentationModel implementations.

For some of you this may all seem quite obvious, and for others hopefully this series will provide some insight as to how one can reduce code redundancy across your Cairngorm applications by implementing abstractions for common implementations.

This topic will be a multi-part series in which I will provide some suggestions surrounding the common patterns of abstractions which can be implemented in an application built on Cairngorm, with this first installment based on common abstractions of Cairngorm Commands and Responders. Other areas in future posts will cover Business Delegate and Presentation Model abstractions. So let’s get started…

Command Abstractions
First let’s begin by looking at what is arguably the simplest abstraction one could define in a Cairngorm application to simplify code and eliminate areas of redundancy – Command abstractions. This example assumes the concern of mx.rpc.IResponder implementations is abstracted to a separate object. For more on this subject see my post regarding IResponder and Cairngorm.

A traditional Cairngorm Command is typically implemented as something to the extent of the following:

The problem with the above Command implementation is that it results in numerous look-ups on the ModelLocator Singleton instance in every execute implementation which needs to reference the ModelLocator.

A simpler design would be to define an abstraction for all commands which contains this reference. as in the following:

As in any OO system there are many benefits to defining abstractions and a good design certainly reflects this. For example, just by defining a very basic abstraction for all Commands we have now eliminated the number of look-ups on the ModelLocator for every Command in the application as well as redundant imports. By defining an abstraction for common references your code will become easier to read and maintain as the number of lines of code will certainly become reduced.

Commands are by far the easiest to create an abstraction for as most commands will typically reference the ModelLocator, and if so they could do so simply by extending an AbstractCommand, if not they would implement ICommand as they traditionally would.

So the first example could now be refactored to the following:

You could take these abstractions a step further and define additional abstractions for related behavior and contexts, all of which would also extend the AbstractCommand if a reference to the applications ModelLocator is needed.

Responder Abstractions
Now let’s take a look at an abstraction which is much more interesting – Responder abstractions. In this example we will focus on the most common Responder implementation; mx.rpc.IResponder, however the same could easily apply for an LCDS Responder implementation of a DataService.

A separate RPC responder could be defined as an abstraction for HTTPServices, WebServices and RemoteObjects as each request against any of these services results in a response of either result or fault, hence the IResponder interface’s contract.

For example, consider a typical Responder implementation which could be defined as follows:

By defining a Responder abstraction each concrete Responder implementation would result in significantly less code as the redundant cast operations could be abstracted, and, as with Command Abstractions, a convenience reference to the application specific ModelLocator could also be defined. Moreover, a default service fault implementation could be defined from which each service fault could be handled uniformly across the application.

Thus we could define an abstracttion for RPC Responders as follows:

We could now refactor the original Responder implementation to the following simplified implementation:

As you can see just be pulling up common references and functionality to just two abstractions we can significantly remove redundancy from all Commands and Responders. As such this allows designs to improve dramatically as it allows for the isolation of tests and limits the amount of concrete implementation code developers need to sift through when working with your code.

It is important to understand that a design which is built in part on Cairngorm must still adhere to the same underlying Object Oriented Design principles as any other API would, and in doing so you will end up with a much simpler design which can easily scale over time.