AS3 ResourceMap API

Of the many APIs I have developed and published as Open Source to the Flex community, the AS3 HashMap has been one of the most popular. My assumption is that this popularity is in part due many developers expecting a HashMap to be provided as part of the Flex Framework, and rightfully so. After all that is why I developed it in the first place.

With the upcoming release of Adobe Flex 3 there are many new additions which have been added to the Framework. These new additions and features are outside the scope of this article; however, one which is of relevance is the ability to directly access the underlying content of a ResourceBundle.

For the most part I tend to think of the content of a ResourceBundle as not begin much different than a HashMap as it essentially is just an aggregation of name / value pairs, just like a HashMap. With that in mind I have developed a ResourceMap API which allows developers to work with a ResourceBundle via an IMap implementation (a.k.a. HashMap).

ResourceMap implements the IMap interface allowing the underlying content of a ResourceBundle to have CRUD specific operations performed on it. To utilize the ResourceMap one only need to instantiate an instance of ResourceMap and pass in a ResourceBundle, as in the following:

The above example is all that is required to work with a Resourcebundle as a HashMap. From there you can work with the ResourceBundle just as you would with a typical HashMap.

The benefit to this approach is it allows developers to dynamically add, remove, update and delete resources at runtime, whereas the new Flex 3 ResourceManager (much like the Open Source ResourceManager API I created last year – had to add that in) does not provide an API for setting resources. In addition, all of the getters defined by the IResourceBundle interface and implemented by ResourceBundle have been deprecated in favor of the new ResourceManager. However, IResourceBundle now provides an additional operation called getContent(); which exposes a reference to the underlying content Object which is created when a .properties file is compiled. Therefore it is possible to take advantage of this by accessing the content object.

Admittedly the thinking behind the ResourceMap API takes a somewhat “outside-of-the-box” approach to working with ResourceBundles as one typically tends to think of resources as constants, especially when working with localized applications. However with all of the new capabilities available in the Flex 3 Resource API (such as loading compiled resource swf’s at runtime, etc) the opportunity to experiment with different things is well worth it!

ResourceMap is published under the MIT license.

February 8, 2008 News
Comments Off on AS3 ResourceMap API

Principle of Least Knowledge

One very important (yet often overlooked) design guideline which I advocate is the Principle of least knowledge.

The Principle of Least knowledge, also known as The law of Demeter, or more precisely, the Law of Demeter for Functions/Methods (LoD-F) is a design principle which provides guidelines for designing a system with minimal dependencies. It is typically summarized as “Only talk to your immediate friends.”

What this means is a client should only have knowledge of an objects members, and not have access to properties and methods of other objects via the members. To put it in simple terms you should only have access to the members of the object, and nothing beyond that. Think if it like this: if you use more than 1 dot you are violating the principle.

Consider the following: We have three classes: ClassA, ClassB and ClassC. ClassA has an instance member of type ClassB. ClassB has an instance member of type ClassC. This can be designed in such a way which allows direct access all the way down the dependency chain to ClassC or beyond, as in the following example:

The above example is quite common, however it violates The Principle of Least Knowledge as it creates multiple dependencies, thus reducing maintainability as should the internal structure of ClassA need to change so would all instances of ClassA.

Now keep in mind that in all software development there are trade-offs to some degree. Sometimes performance trumps scalability or vice-versa, other times readability trumps both. A perfect example of where you would not want to use The Principle of Least Knowledge is in a Cairngorm ModelLocator implementation. The Cairngorm ModelLocator violates the Principle of least knowledge for good reason – it simply would not be practical to write wrapper methods for every object on the ModelLocator. This is the main drawback of the Principle of least Knowledge; the need to create wrapper methods for each object, which are more formally known as Demeter Transmogrifiers.

The goal of good software design is to minimize dependencies, and by carefully following the guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

February 2, 2008 Agile / Code Review / Design Patterns / News / Object Oriented Design / Software Engineering
1 Comment

SQLite Administrator

When developing application in Adobe AIR which utilize the SQLite API it is often useful to have a quality SQLite editor available, especially during development and testing.

I have tried many different SQLite editors, most of which were quite good, however the best of the bunch you have to pay for.

Personally I recommend SQLite Administrator. SQLite Administrator is a powerful tool which allows for the design, creation and modification of local SQLite databases. The code editor is very intuitive and provides a simple UI which allows you to write SQL queries with little effort. In addition, there are many useful features which you would expect from a quality editor such as code completion and highlighting.

SQLite Administrator

So if you are looking for an high quality free SQLite Editor when working with Adobe AIR and SQLite check out SQLite Administrator

January 24, 2008 News
4 Comments

Flex Unit TestSuiteHelper

Test Driven Development is an essential part of any software project. Leveraging Flex Unit in your Flex and AIR projects is a well known best practice and will inevitably result in less unknowns and provide a much more reliable codebase, however like most things in life that provide value, unit testing comes at a cost: Time.

In general, writing Unit tests is often an overlooked process as it ultimately equates to an additional level of effort (time) in a project plan. However, writing unit tests should not be over looked for a number of reasons, and in my opinion most importantly because it forces developers to understand what problems the code they write are intended to solve, thus resulting in a better understanding of the problem domain.

Now without getting into a lengthy discussion about the benefits of Test Driven Development, as there is plenty of information available on the subject, I am going to focus on how to make it easier in Flex.

Typically when I write a unit test I stub it out and then run the test runner to make sure it fails. I pretty much do this immediately after I write the test and then I see that my test did not come up and realize I never added it to the test suite. Obviously something like adding tests to a test suite can be an automated process which would allow unit tests to be developed a little faster as all that would be needed was to write the test.

So in an effort to simplify the process of adding tests to a test suite I have developed a TestSuiteHelper which is a simple utility class that automates the process of adding unit tests to a test suite. Rather than manually adding each test the TestSuiteHelper will automate the process simply by invoking a static method and passing in the test class from which you need to extract all of the tests.

So if you would like to simplify your team’s unit testing workflow feel free to utilize the TestSuiteHelper.

January 18, 2008 Software Engineering / TDD / BDD
4 Comments

API Design: Method parameter objects

When defining a constructor or method with more than three parameters it is considered a best practice to create a parameters object for holding the values which are required. This especially holds true when some of the parameters are optional (as they will contain default values) and also when two or more consecutive parameters are of the same type (as developers may accidentally transpose these parameters – which will not result in compile time or runtime errors, making debugging a nightmare!)

The most appropriate solution for such cases is to break up the method into separate methods, however when this is not feasible creating a parameters object will improve both code readability and provide a cleaner design which leaves less room for unexpected errors.

Consider the following method:

The parameters defined in this method are typical of what you will often see, however it is much cleaner and reliable to create a parameters object for holding these parameters. In addition, a parameters object allows for a much easier client implementation as default values need not be reassigned for all parameters which proceed a parameter which you need to specify a value other than the default value. For instance, if a method accepts 5 parameters and the first two parameters are required but the last three are optional, if you you need to specify a value for the last parameter you will need to re-assign the default values for the proceeding parameters, when in fact you really only need to specify three parameters.

The following example demonstrates creating a parameter object which can be passed to “someMethod”:

When invoking “someMethod” clients can now simply instantiate an instance of the parameter object, set values only for what is needed and pass it in as follows:

So if you would like to improved code readability and provide proactive exception precautions, consider utilizing parameter objects for methods which require more than three parameters.

January 12, 2008 Code Review / Design Patterns / Object Oriented Design / Software Engineering
2 Comments

Quick Tip: Cairngorm Best Practice

When developing Flex applications in Adobe Cairngorm it is quite common to define all event constants as follows:

The problem with this design is that there is no way of guaranteeing the event type will not collide with an Event type in another package.

Now, I think it is only fair to say that in a good design there typically would not be two Events with the exact same name. However, when developing large scale Flex applications in which additional modules are added with each major release, not to mention the fact that there can be literally hundreds and hundreds of classes, the chances of creating an Event with the same name begins to increase.

As a best practice you should assign the Event type a value which is identical to the Event’s fully qualified class path. This will ensure there can never be a collision of Event types. An example can be seen in the following:

It’s always better to be safe than sorry.

January 10, 2008 Code Review
8 Comments
← Older Articles
Newer Articles →