12.5 Clean API

A pplication programming interface (API) is a general term for how one block of code communicates with another. For example, each ActionScript class defines an API by making methods and properties available (or keeping them hidden). Keeping the API for your application clean, with well-defined properties, methods, and events, makes for fast programming by the rest of your team. A formal API helps to insulate one code module from changes in another module. Furthermore, updates to an application can be made more quickly if your properties, methods , and events are predesigned, documented, and consistent with the API that you set up.

12.5.1 Reusable Code

Making your code reusable is one of the ways that you can improve the speed of coding in future applications. You should maintain stock objects and snippets of code that have been programmed, tested , and optimized in the past. For example, most applications have users, so if you maintain a standard User object that interacts with a User remote service, the two parts can be utilized over and over. There is no sense in reinventing the wheel each time. Even if an object or piece of code can't be used in its entirety, it can be used as a starting point. Developing a useful library of ActionScript or server-side code (or benefiting from libraries made available by others) can increase your productivity by orders of magnitude.

12.5.2 Modularity

Keeping the program modular is not something that is confined to one style of programming; it is a concept that works in all cases. If you code is self-contained in modules, you have several advantages over code that is nonmodular:

• Code in a module can be tested without relying on other parts of the application, by simply knowing what the code requires and what it returns.

• Modules can be improved and replaced without affecting other elements of the application, assuming your new module does the same thing with the same properties, methods, and events associated with the old module (i.e., as long as the API to the module doesn't change).

• A test module can be plugged into the application in place of the real module, to facilitate easy testing.

• Other programmers who might need to work on the application can understand the code more easily.

Having modularized code does not simply mean separating the code into sections. I worked on an application once, built by a fellow programmer, that was broken down into several include files. At first glance, it seemed logical that the program was broken down as it was. However, after diving into the code, I could see that each file had elements that relied on other files ( variables , functions, etc.), which made it very hard to update the application. In the end, I wasted more time trying to figure out what went where than the time it would have taken to rewrite the code using a more logical approach. Therefore, trying to maintain modularity can help alert you to poor application design. If you can't modularize your code, you probably need to redesign it, even if it means starting over.