o learn how to do something well, following in the footsteps of those that have successfully done it before can be a useful practice. Think of the age old master/apprentice system, which works well and is still used today. In medicine, for example, the chief resident can be considered a master and the intern the apprentice. This principal is especially effective—yet consistently ignored—in software development. Many developers, working in isolation with little or no budget for books, are forced to recreate what has already been created and re-learn what is already known.

Fortunately, masters are available to those programmers who will apprentice themselves. Patterns and anti-patterns are a body of work that can play the role of master. Patterns are general blueprints for solutions to known problems. These blueprints, when implemented correctly and applied to the correct kind of problem, have proved effective. Anti-patterns are the opposite: solutions that are known to fail.

Patterns currently come in three flavors: creational, structural, and behavioral:

• Creational patterns deal with object creation.
• Structural patterns deal with class and object composition.
• Behavioral patterns address object interaction and the distribution of responsibility.

Because patterns are evolving and still being discovered, very few are experts in them. However, the number of pattern practitioners is increasing, and several excellent references on patterns are available today. (A must-have for every practitioner is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, et. al.) In fact, many patterns—and more recently anti-patterns—are well documented, and you can easily find many successful examples.

This article discusses a pattern that is both easy to implement and easy to use in Visual Basic 6, the State pattern. VB6 can be prone to disorganization and the State pattern, a behavioral pattern, is a consummate organizer.

Dynamic Object Reclassification
Typically, problems arise when a form tries to do too much. For example, suppose you can interact with a form in the following states: browse mode, edit mode, and administrative mode. Generally, you end up writing a lot of conditional code that depends on some flag—let's say a mode flag for argument's sake—and uses a lot of conditional checks to turn controls on and off and permit editing and updating based on the state of this flag. The result is generally spaghetti code of varying disorganization.

Now, I am not impugning anybody's dedication or desire. What I am saying is that requirements typically evolve and change, and complexity insidiously winds its way into code. Proactively using the State behavior pattern can prevent behavioral complexity, and reactively using it can eliminate such complexity once it rears its ugly head.

The basic idea is that a particular class represents a context. A good example is a form. The form is coded in such a way that a state object, an interface, defines its behavior. A behavior class implements the interface for each state possibility. By dynamically changing the instance of the state object, one changes the behavior of the context—in this example, the behavior of the form. This is referred to as dynamic reclassification.