Hi Randy,

> my REAL question: "How do you (or I) write reusable code??"

How can I write a book and become a billionaire? Some questions are easier to answer afterwards. *s* Most people have different ideas of writing reusable code. Most people even mean different things with "reusable". It can be code that you reuse in one application, that is, centralize code. It can be code you want to use in many applications, or code that is used by many. The wider the scope the harder it is to achieve reusability.

First of all you need to be clear what you want to re-use. It can be the UI, certain functions, a process, and so on. For most of them you would create non-visual classes that - if needed - provide hooks for the UI. A non-visual class doesn't have to be a custom object in a PRG, it can be a non-visual label, as well. That depends on whether you prefer VCXes or textual code. For UI stuff you obviously use visual controls. Most put them into VCXes, some into PRGs. Reusability is easier to achieve, if you don't mix the two. That is, a form class (visual component) should never have any significant amount of code.

The second issue is when you write reusable code. In my experience you shouldn't start too early. In general, I follow the rule to write code non-reusable the first time. When I encounter a piece of code the second time, I improve the code and think through it, but still keep it separate. The third time I'll turn it into a reusable component.

You also need to find the right abstraction layer. For instance, you might have a textbox for a ZIP code that the class validates. There are several steps of abstraction possible:

a) It's a UI component. Create a textbox that validates the ZIP code.

b) It's a function: Create a class that validates a ZIP code. Then create a textbox class that calls this code or provide a builder that adds the two lines to the Valid event.

c) It's a problem called data validation. You create a component that performs data validation for a set of controls. Each control can be linked with a set of rules. Each rule is a component that performs generic validation. One of these rules is a ZIP code validation. Another class provides the infrastructure for visual feedback in the case of an error. Several provider exist, such as displaying a messagebox, a status bar text, a yellow error bar at the top of the form and red dots on the side of the input control.

That is when you have to think of some bigger pictures. Depending on how the application structure is, some code suddenly belongs to the business layer, some to the UI layer, some just to the application if you don't have such layers. With the layer concept you now end up in the discussion where certain validations should be performed, whether there is UI side business rules and data side business rules, or just business rules, and so on. If you continue to follow this path you end up in some agile model-view-controller based SOA mesh cloud application. ;-)

Getting back to coding... When you write reusable code it's important to test. I use FoxUnit for my generic code so that I can make changes years later and still know that my class works the way it supposed to work. The unit tests also nicely document the dependencies.