Blog

One of the most important tenets of Object Oriented Programming is loose-coupling. This is the idea that entities within a system should have as little ‘knowledge’ of each other as possible.

We achieve this by layering other concepts such as encapsulation, interfaces, and schema-based messaging. Loose-coupling is important because it leads to more maintainable, and reusable code. But reusability is something we strive for within the bounds of the language and/or development platform that we happen to be using at the moment.

Since there are so many differing technologies available, we pick one and build upon it. Other platforms don’t really figure into most developers’ day-to-day work. We live in ‘technology silos’; generally oblivious to competing or tangential technologies. It is difficult enough to truly master a single platform. Of course many developers dabble in more than one language, but mostly their knowledge and practice of each is mentally cordoned off from each other.

Why not take advantage of the most advanced language or toolkit features?

For instance, if you develop in both Python and Flex, your knowledge of Flex’s binding capability really doesn’t give you any advantage in your Python programming. Of course binding is a beautiful thing, but it isn’t universally portable. It isn’t a concept that is entirely unique to Flex, but the implementation of it certainly is. Thus, an application whose core architecture relies upon data binding would have to be entirely reconceived on a platform without it.

The same goes for dependency injection via compiler metadata. There are Flex-based frameworks out there based entirely upon it as a way of achieving loose-coupling. It’s really slick but it won’t help you anywhere but in Flex. If you employ an architecture whose core functionality is based upon Flex compiler directives, what is the chance you’ll ever be able to port it to another language? I’m not a gambler, but if I was, I’d place my bet at another table.

This article is about portability, why it’s important, and how PureMVC helps you to achieve it.

Portability of code is a second-order form of reusability. It is the ability for the architecture, if not the actual code of your application to be reused on another platform.

Of course, if you’re building a Flex application, you’re probably asking yourself why you’d even care about the portability of your code. If you’re on a team of fifty developers building a massive enterprise application in Silverlight or Java, for instance, why would you care if the code you’re writing would make an Objective C or Python programmer scratch her head? Who cares what the people in those other silos think about your methodology? What possible practical purpose could there be in it?

The answer lies in the simple fact that, as Steve Miller so aptly put it: “time keeps on slippin into the future.”

Building Pyramids out of Bits

As developers, we are building pyramids out of bits, sand-castles by the shore. If you listen to the echo chamber these days, you’ll hear people portending the death of Flash at the hands of HTML5. Because Apple decrees Flash broken, even some of the oldest Flex developers I know are wiggling in their seats and hedging their bets by learning Objective C and HTML5. Just in case. Regardless of what you think about the value and strengths of the technology you’re using, its longevity in the marketplace is not guaranteed by ‘survival of the fittest’. Corporate politics and whims have far to much to do with it. Like it or not, one day your favorite platform will be but a fond memory. So when you are developing that huge application that your enterprise client will likely rely upon for many years to come, consider what their maintenance of the legacy will look like in 5 or 10 years.

I’ve been developing professionally for over 25 years, and I’ve seen a lot of platforms (both hardware and software) come and go like the shifting sands of the Sahara. I started out poking hexadecimal values into memory locations in machines like the Commodore 64. I knew where every free bit was in the memory map of that computer. None of it (to my knowledge) survives today.

Then, many of my early years in the realm of business programming were spent maintaining creaky old accounting programs written by others that ran on what are now long-dead minicomputer platforms. I am not joking when I say that platforms will literally disappear and take your code with it if you’re not careful.

And today, it’s not only the passing away of your most cherished platform that presents a pressure to write more portable code. It is apparent from sheer sales volume that portable computing looms large in our future as developers. And consider the fractured market. If you are writing a mobile application, you must write it for more than one platform if you are to succeed in grabbing any significant market share. Blackberry, iPhone, Windows CE, Symbian and the rest of the mobile herd all have slices of the pie, and it is a Tower of Babel from a development perspective. Building and maintaining an application on more than one platform is bound to be challenging; even more so if you aren’t writing portable code.

So how does PureMVC help you achieve this vaunted portability?

It does so in several ways.

Firstly, it is based upon long-proven design patterns. That is, the roles, relationships and collaborations of the actors in a PureMVC program are widely understood, inherently portable and can be implemented in virtually any OOP language.

Secondly, it doesn’t rely upon platform-specific magic like namespaces, data binding or compiler directives. It uses the simplest language constructs to ensure that the basic architecture of your application can be reproduced anywhere that PureMVC can be ported. And if the framework itself isn’t currently available for the platform you’re targeting, experience with the project over the last 4 years has shown that it generally takes only about one focused weekend for a developer to port it.

And last but not least, the scope of the framework was determined from the outset, implemented, bug-fixed to maturity and left at that. This is what has allowed it to be ported to so many platforms since its humble beginnings in ActionScript. It has a solid, and unchanging reference. Don’t let the fact that there hasn’t been a new version of PureMVC for several years fool you into thinking it is a dead framework. To the contrary, it means that you don’t have to continue to try and match your skills and code to a moving target. Each time the platform you develop for advances, you must put on your running shoes and try to keep up. That’s an unavoidable, tiring and unending marathon but PureMVC will not contribute to your weariness. It is what it is. It is aided and extended by various utilities which are themselves portable, but you can take them or leave them in a la carte fashion.

Of course each language and platform will have its own syntactic sugar and requires a separate codebase, there is no avoiding that. The boundaries of your application (services and view) will always require some platform-specific implementation touchpoints, but the bulk of your application’s architecture is sandwiched between and therein lies the  potential for portability.

If you were moving a large enterprise app from Flex to Silverlight or reimplementing an the iPhone app for Blackberry, would you rather start from scratch or migrate? If all the roles, responsibilities and collaborations remain the same, migration is the path of least resistance. Not only will it save time and money, it will leave you with more maintainable code.

Consider the PureMVC EmployeeAdmin demo. It is a simple but nontrivial example of how to move data between the model and view tiers of an application. This canonical demo has been ported from the original AS3 /Flex to Objective C / iPhone, C# / Silverlight, C# / WPF, Java / GWT, Java / JavaFX, JavaScript/MooTools, Python / wxPython and Ruby. Of course, each implementation varies as it must to accommodate the platform, but the essence of the application remains the same. If you know PureMVC in one of these languages, you can study one of the other implementations to help you learn a different language. It is like a Rosetta Stone for learning PureMVC and how it can help you to achieve more portable code.

Update 2016: “I hate to say I told you so, but…”

This article was originally written six years ago, in 2010. Since then, Adobe Flex, the platform I’d been building with since 2004 has died a horrible, fiery death. The last Flex project I worked on was a massive, modular Flex-based trading application at a multinational bank. They had declared it time for the “Flexit” (the Brexit vote was looming, and much of the team was located in London).

The application being migrated was built on Parsley and my team was in charge of transitioning it to HTML5. There is no analog of Parsley in HTML5, although Angular comes closest, because it shares an intense focus on dependency injection, so it was the lucky winner of the team’s framework survey. Angular does a better job of suggesting an overall architecture, though, so the codebase ultimately benefited.

But make no mistake, it was definitely a burn-down and rebuild operation.

Had it been PureMVC, the JavaScript port would have been waiting with open arms, and migration would have been straightforward, since all the classes and their relationships would remain as they were before. Even the project code’s folder structure would have been the same. All that would need reworking would be the view components, which could be done with React, which mates nicely with PureMVC since it doesn’t impose it’s own MVC (or MVVM or whatever) philosophy.