Aral Balkan

In my post on the Ariaware RIA Platform (ARP), I mentioned that while working on the first release of Opal, we had implemented View Helpers as part of our pattern-based framework for that project. Although this seemed like a good idea at the time, as the application grew, I noticed that it was partly responsible for much of the code duplication we started to experience. This led, among other things, to us not incorporating View Helpers into Bits and Pixels' own, AS2-based framework, ARP. (ARP also differs markedly from the Opal framework in our implementation of the various patterns, including the event broadcasting and handling model as well as the behavior of the controller and commands.)

Working with Telrock Communications, we are currently refactoring the Opal framework to bring it in line with the best practices pattern implementations we developed for ARP. These include, among other things, removing the View Helper classes (and encapsulating View Helper methods as public methods within the various forms/screens themselves) and adding view references to broadcasted application events (to be used by the Command classes). But why are we undertaking such a large-scale (and thus risky) refactoring of the base code in the run up to a second release? The answer, as always in refactoring, is to remove duplication.

A Command pattern implementation that does not allow the commands to receive view references leads to a very unhealthy duplication of Command and View Helper classes. As we all know, duplication is bad and refactoring is the answer. We actually noticed this issue late in the game in the run up to the first release of Opal and though we should have refactored it there and then, we decided that we couldn't afford the project risk at that point in time. Whether or not that was the right decision can be debated. Personally, I believe that Kent Beck couldn't be more correct when he states that the right time to refactor is the moment you notice duplication. This is related to one of the most important tenets of eXtreme Programming: Courage. (The courage to refactor when necessary.)

The removal of View Helpers is necessary to achieve better encapsulation and reduce code duplication. With the View Helper functionality neatly encapsulated within the various forms/screens themselves, we remove the need for code duplication (through the duplication of View Helpers) when composing new, aggregate screens or extending existing screens. With Commands receiving view references, we remove the need to duplicate Command classes when extending screens or composing new screens from one or more existing ones.

With these refactorings in place, the Opal framework should behave in a functionally equivalent manner to the Ariaware RIA Platform. Among other things, this is expected to result in a considerable file-size reduction in the application and aid in its scalability and maintainability.