OOP Sacrilege

One of the first things a programmer learns is to reuse code. One of the first things an OOP programmer learns is to build objects that are encapsulated. Encapsulation is an easy principle to understand, and should be thought of as the Prime Directive when you are programming using OOP. Encapsulation is simply the concept of hiding the implementation of an object by exposing properties and methods that do not change. If you look at a simple example of a Car object, you might have methods drive(), steer(), accelerate(). Your properties might be color, size, and speed. As long as you develop this Car object and maintain these methods and properties, anyone who uses the object will be able to maintain their programs. For example, you would not release a new version of Car that had a method named doDrive() instead of drive(), or goFaster() instead of accelerate()-- this would break everyone's applications, and would also break the rules of encapsulation. Your objects should be thought of as black boxes--the implementation is hidden, but the way you use the black box remains the same.

Another example would be a VCR object. When you think of a VCR, you think of various functions that remain constant--the Play button, for example. As long as the VCR object has a Play button, your interaction with it will not have to change. As long as the properties and methods do not change, there should be no reason that the object will fail in future applications.

Well guess what? This is exactly what Macromedia has done in Flash MX 2004--mostly in Flash Pro. They have taken well-established objects--UI components--and made arbitrary changes to the way these objects are accessed.

I'm not talking about the change to a new component architecture, the new ActionScript 2.0 implementations, or the the fact that there are new versions of old components. I think that MM had to make a change, and I'm very pleased with the update to ActionScript 2.0 while still maintaining ActionScript 1.0 compatibility. MM should be applauded for making this change and doing it in a responsible way. I'm talking about encapsulation--building objects that hide their implementation from the user, thereby allowing the user to use the objects without worrying that the implementation might change. Macromedia must have skipped that class.

Here is a simple example. The checkbox component is one of the most basic components you can have in an application. They have been around for years in every conceivable environment. If you build a web page using an HTML checkbox in 1996, you can still access the checkbox today. A checkbox is a checkbox is a checkbox. Right? Wrong. There is a Flash MX checkbox and a Flash MX 2004 checkbox. This simple piece of code from Flash MX will fail in Flash MX 2004:

trace(myCheckbox.getLabel());

this will fail as well:

trace(myCheckbox.getValue());

Why? Is it related to the new component architecture? No. Is it related to the switch to ActionScript 2.0? No. It is related purely and simply to bad planning and poor communication. Macromedia could have implemented a checkbox and allowed the user to access getLabel() and getValue() that returned the expected result. Simply put, there is no reason why a checkbox built in early 2003 should not work the same as a checkbox built in late 2003. Was the old syntax deprecated? No--it was just thrown away and a new syntax brought in.

This is just one example. Another is the DataGrid. True, Macromedia did not implement a DataGrid in the initial release of Flash MX, but they did put one on the first DRK--this grid is in use by many people. Now, Flash MX Pro comes with a DataGrid that does not use the same API. Even a simple thing like setting column names is implemented differently:

Flash MX

myGrid.setColumns("Name","Age","Sex");

Flash MX 2004

myGrid.columnNames = ["Name","Age","Sex"];

Why the change? Who knows. Could MM have implemented a setColumns() method in the new DataGrid so that it would be compatible with old code? You betcha. All I can say is that there are a lot of people disappointed with the lack of consistency from one version to the next. Forget about DataGlue -- it just plain doesn't work with Flash MX 2004 components, even with the Flash Remoting updater.

There is also a major compatibility problem with the way the new components are addressed: listeners are used now, as opposed to callbacks in the previous component architecture. The new approach is a worthwhile change--listeners should be used from this point forward--but why no backwards compatibility with the old techniques?

I'm not saying that the component architecture is bad in Flash MX 2004. I'm not saying it didn't need to be updated or even completely overhauled. That is not the problem. The problem is, how can we trust that anything we build today will be usable in the future? If a simple checkbox, combobox, or even text field cannot be made consistent from one version of Flash to the next, how is a programmer supposed to maintain or update existing applications without having to relearn property names, method names, and event names?

Some things work the same way as they did in the last version of Flash. There are a good number of properties and methods that did not change between versions. For example, many of the methods of the button and combobox still work. This is great, and how it should be done. A combobox is a combobox is a combobox. For the Flash programmer, it does not matter if he is working in Flash MX or in Flash MX 2004--he can drop a combobox on the staqe and use consistent methods: addItem(), addItemAt(), etc.

In most languages and environments, when a method or property is removed, there is a period where the syntax is deprecated. This allows developers to note the change, and begin using the new syntax for future projects. Backward compatibility seems not to be of much concern with Flash, but it should be if it is to be taken seriously by programmers.

Another consideration is the documentation. If there is a change, it needs to be documented. I open up the Flash documentation for DataGrid and get this:

Method summary for the DataGrid class

Interesting. . .considering the documentation was non-existent when Flash was released, and updated once about a month ago, now I see methods for PopUpManager and Accordian in the DataGrid docs! Documentation is the single most important aspect of a programming environment. Without it, a programmer is lost. Yet another reason to maintain properties, methods, and events from one release to the next.

UI components are nothing new. Yeah, we've only had them in Flash since Flash MX, but UI components have been around since the early Macintosh and Windows operating systems. They have been in every major visual programming language, including VB, Delphi, and different environments for Java. They are in HTML. Someone at MM needs to seriously sit down with a pen and paper and plan for the future, rather than making it up as they go. There are hundreds of thousands of people using Flash. When you arbitrarily say "Let's change this to this" or "Let's build a new component and forget about the old component" there will be many people affected by the change. The "black box" principle is more of a Pandora's box when dealing with Flash. We can only hope that Flash 8 will be consistent with Flash 7.

Tom Muck -- October 2003