In Flash programming, perhaps more than in any other kind of web programming, people seem to be code-reuse-happy. Maybe that's because ActionScript has the capabilities of doing more things than most other languages. We can create data models and write controller logic with the same languages that can make a bitmap blur, fade, and spin. There's so much breadth to ActionScript that we instantly look to see what bit of code we (or someone else) wrote way back when to do that very particular thing we need to do today.

So, often is the time that I'm asked if a certain bit of code is reusable. "Can we reuse this codebase to make the very same XYZ as that XYZ? Only...with these 11 minor differences?

I instantly cringe. Because, in reality, all code is reusable. You just copy the codebase over from one folder to another and poof, we've reused it! Slap on 11 hacks and you've got yourself a nice new duct-taped application thank you very much.

Reuse is in the idea behind the code, not the code itself. In fact, when I develop, I don't think in terms of whether this class or that class is reusable, but I think of whether the general idea behind why I wrote this or that class is reusable. Some might call the general idea a design pattern.

At Xoprecious, we're constantly updating and modifying our library of reusable code. In doing so, I've found that truly reusable code does less. It interferes less with the application. It sits on the sidelines with an occasional helping hand as I steer through the logic mainly on my own.

The amount of code you write has little to do with how hard it is to write that code. In fact, I find that the more unique code I have to write around my reusable code, the better I understand what's going on. I've had the reverse case happen all to often...letting reused code structure the vast majority of the application. Meanwhile, I'm steering through an unsettling amount of code I'm not truly familiar with, hoping that I can chip away and add on bits of syntax here and there without letting the whole ship fall apart.

Here's an example. Recently, we decided to build a reusable code base for Flash forms. The idea here was to figure out a nice way to handle form validation management. In Chapter 8 of our book, we write an interesting technique to handle validation. The code itself contains a form validation manager, tracking the form parts that need validation and lets you assign different validation strategies (class instances that handle validation, like a number validator or required field validator) to different UI components. These components were linked to custom wrapper classes that expected every form component to have a label, a form element (like a radio button or text field) and an area for validation alerts.

All fine and dandy, but what if I wanted to not have validation alerts pop up next to each form element? What if I wanted to just write out all validation flags in one dedicated spot when a user hits submit? What if I wanted the form component to pulsate red when it didn't validate? If we had simply reused this codebase as is, it would've been a whole lot of rewiring to figure out how to hack the current structure.

Instead, I rebuilt the codebase for forms. The new codebase unties the visual cues from the validation. Each form element that needs validation has to add itself to the form validation manager as it did previously, but now, you provide the validation manager with a callback function after validation is run against it. The callback functions, which you have to custom create each time you write a new form, can obviously do what it pleases. In theory, it seems like more work. The reusable code has been reduced to just a bunch of validation classes and one manager, and the work of deciding what to do with the validation information has to be done each time you write a new form. But, this is what makes the code truly reusable. The idea behind it is that it lets you code your form in exactly the way you want, lending a helping hand when you want to check that a number is between 1 and 100, an email is in the correct format, or that a text field has data in it. The reusable code does not tell you what you should do with that information at all. It's job is simply to manage what you want to have validated, and let you know how that validation went. What you do with that information is up to you.

Now, perhaps, 6 out of 7 times, I might want the rigidity of what the original Chapter 8 code offers. But, still, by letting the reusable bits do less, I instantly get more familiar with the actual application I'm working on rather than feel less intimate with it because the reusable code is doing more.

I think truly reusable code follows this litmus test: When you reuse code, does it make you understand how your code works less than if you wrote it from scratch? In the case of the new form libraries I've written, it passes. I know what its purpose is and I know where it gets out of the way, letting me write (and understand) all the unique parts of my application.