It seems that recently people, good people, are coming out of the woodwork to point out that they might not always like to deliver their Flash Platform solutions as OO solutions. I hear the collective gasp of horror and revilement from the community of Actionscript developers who have spent years refining their coding and OO methodologies to a point where they can code in Java with little effort. I myself am one of those coders. However, I am forever using the term â€˜Pragmaticâ€™ when I speak to staff and peers alike. Look at the big picture. Not everyone wants a solution that takes 2 months to deliver because you have to develop redundant, reusable, unit tested OO code. Many clients want throw away solutions and have no likelihood of code reuse. The problem is that weâ€™ve become enamored with the idea of perfecting and using only code. Anyone who speaks of the timeline does so with contempt and some even call for itâ€™s removal altogether, suggesting that it is the province of antiquated, knuckle dragging wanna-be coders. Not like us â€˜realâ€™ coders.
Well, let me stop you right there. It could equally be argued that components are the province of lazy or just plain bad coders who wonâ€™t or canâ€™t do the code them selves. Of course this is not true, or at least itâ€™s not true of well written components. They serve to reduce development time, simplify solution requirements and yes, in some cases, allow less skilled developers to produce the same results as highly skilled developers whilst learning better coding practices at the same time. No one disagrees with the use of components for all these reasons, in fact they extol them. Interestingly, the very same arguments can be used for the use of timeline solutions, where timeline solutions are appropriate and employ their own best practices. How then can this be a bad thing?
As is being pointed out a lot recently, Flash/Actionscript, is NOT java or C#. Itâ€™s getting there, but letâ€™s not forget that it has itâ€™s own unique, inherent strengths and believe it or not, the timeline is one of them! Letâ€™s not abandon the old strengths of Flash / Actionscript for the sake of the emperorâ€™s new clothes. Using OO based code solutions when appropriate and timeline when itâ€™s pragmatic allows us to produce the right work in the right time for the clientâ€™s requirements. This is an example of good process at work. Flash is an amazing tool, capable of an entire spectrum of solution options. This diversity of solution options is a strength, not a weakness. If you want to be a Java developer then by all means be one, but if you want to be a Flash developer then extol itâ€™s great diversity of strengths, from full on OO to timeline. Donâ€™t be cajoled into admitting that Flash is a glorified coloring in tool by code snobs. Tell them theyâ€™re wrong! We can produce the same solution in 2 or 3 equally valid and completely different ways. Imagine how hard it would be to produce a coding tool that actually allowed for all 5 members of the Dreyfus Model of Skills Acquisition to operate. I seriously believe that there is no other software tool that does this. It should be celebrated with pride, not hidden in shame and though many of us use best practices, good process and pragmatism to produce the right solutions for our customers actual needs, Flashâ€™s diverse solution palette is all to often reduced to just OO class file options in an effort to look professional.
Adobe need to stand up and support their huge Flash developer base on this matter to. For to long they have pushed Flex as the right choice and insinuated that if you prefer Flash then you are a Mickey Mouse developer. The reality is that we have all options and can help developers from novice all the way through to expert. Iâ€™m not condoning using the Flash API for coding as Adobe have failed to improve their actionscript code panel in line with their Flex one (some might say this was deliberate).