Don’t Cha Wish Your Methods Can Overload Like Mine?

Yes, yes I do.

On my previous posts, I wasn’t exactly silent about my love towards the combination that is ActionScript 3.0 and Flex. However, just like a romantic relationship, after the initial flowery period is over, you start to see the ugly side of things.

For our 3rd coding task, we are to finally get down to business and start development on the SQL Builder application. The tentative goal is to reproduce the same user interface as the one we came up with for our paper prototype and user testing phase. Since this is a major step towards the final product, we are going to treat it as the final product which means we will need to design the code structure in a coherent manner to promote readability, reusability, and extensibility. We do not want another round of throwing away code because we feel we have enough practice already. It is time for the real thing.

After some deliberation, we decided to use the Model View Controller (MVC) architecture to separate our code into logical sections. As well, we noticed that in our previous demos the code in our main file looked like angel hair pasta from the mix of markup and javascript-ish code. To rectify that, we are using a code-behind approach to leave the main file purely as mxml markup and “behind” it is all the Actionscript logic. In addition, we are going to be placing the classes in packages. Aside from the main benefit of having class structures separated properly, having the fully-qualified names of all of our classes being prefixed with edu.toronto.cs.flareflow feels strangely gratifying (import statements look cool!). Lastly, we are going to be using interfaces and abstract classes in our design to take advantage of polymorphism. This is especially useful for the many types of “boxes” that share the same basic input/output functions.

Pretty exciting stuff no? We had our concerns in implementing everything we described above, but we did research into whether or not they are feasible before going ahead. So far we are able to accomplish the first three in a relatively clean fashion. The hiccups came in when trying to get the interfaces and abstract classes going.

Having used abstract classes and interfaces from other more full-featured programming languages, when I read that it is possible to use these constructs in Actionscript, I took it for granted that they will work exactly the same way in Actionscript as they did in say, Java. I was flabbergasted when the compiler told me my classes + abstract classes + interfaces were illegal. After combing through reference manuals, I discovered these nuances about Actionscript:

1. No clean way of using singleton pattern – Constructors must be public. People online recommended throwing an exception when someone tries to instantiate the class using new and not the newInstance method … I don’t like this solution.

2. No method overloading – if I am trying to create another method of the same name with a different number of parameters in order to suit my specific class’ function better , it is not allowed.

3. No abstract classes, no abstract methods– Abstract classes in Actionscript can be “simulated” by writing them as concrete classes and then you either: A. Throw exceptions when instantiated or when unimplemented abstract methods are called. B. Write HUGE comments alerting the user to make sure to extend this class and not use it directly.

There are many “hacks” floating around the web to work around the above problems. We are still deliberating on whether to use these hacks or change our design because the hacks do result in a bit of somewhat ugly code.

The biggest problem I have with this is that it weakens the power of inheritance and encapsulation. I don’t see why I should be using inheritance when I can just encapsulate by composition. Aside from adding a bit more code per class and perhaps not making interface contracts as obvious, there doesn’t seem to be a significant downside. Hmmmmm… am I missing something?

In any case, the initial exciting period for Actionscript + Flex is over. Relationship authors call this “The Power Struggle Stage”. This is the stage when most breakups and divorces happen. Aside from noticing faults in the other party that were not apparent before, people in this stage also start to notice or seek out alternatives. So… I guess…. Hello Silverlight?