When I write a new class, I start by using it before I create it. I write some code using the class as if it existed, and then I declare a few object variables. If the class has a Create method, I call it in different ways to create different objects. Next, I set some object variables to refer to existing objects. I pass objects as arguments to subs and functions. I assign values to or read values from the properties of the objects. Finally, I call the methods.
It’s easy and it’s fun. I never get design-time or run-time errors. Imaginary objects of imaginary classes can acquire new methods and properties as fast as I can think them up.
But we all know that air code doesn’t work. Once I start implementing methods and properties, some of them turn out to be more difficult than I expected. Sometimes I have to cut features or change the design. When I change the implementation, I change the test code to match.
When the implementation gets to a certain point, I start using it, one feature at a time. I comment out most of the client code, and implement some key properties and methods in the server code. Gradually, I uncomment more and more of the client code until everything works. Design is an iterative process. When you actually try to use your implementation, you might find that it’s clumsy. Or you might find that your client code wants to do something that can’t be done. Often, the process of implementing might give you new ideas for features that users would appreciate.
On major projects, you don’t always have the luxury of designing by trial and error. A designer might write a specification describing all the interface elements in detail. The spec is then handed to an implementor, who makes it happen. Interface changes can have major repercussions for everyone involved. Even in this situation, however, the designer follows the same process, if only in his or her imagination. Any design-implementation process that depends on the infallibility of the designer is bound to fall short. I’ve seen language specs aplenty with sample code that never worked and never could have worked—or, worse yet, specs with no sample code. If you find features that don’t quite seem to be designed for programmers on this planet, you can guess that the designer never actually tried out the feature—either in a virtual or a real sense. Unfortunately, we’ll soon have to deal with some Visual Basic features that match this description.
We’ll follow a use-first-implement-later strategy with the CDrive class, and you’ll see a lot more of it throughout the book. Of course, I get to cheat; you won’t see all my stupid ideas that got weeded out during implementation.