One of the most important tenants 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 oblivous 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. For instance, if you
develop in both Python and Flex, your knowledge of Flex's binding
capabilty 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 reconcieved 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. 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. This article is about portability, why
it's important and how PureMVC helps you to achieve it. 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." 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
dissappear 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, bugfixed 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 vaious utilities which are themseleves
portable, but you can take them or leave them in ala 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
reimplmenting 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
resistence. 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 non-trivial example of how to move data between the model and view
tiers of an application. This cannonical 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 accomodate 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.
|
