Creating bulletproof property procedures

In many cases, assigning an invalid value to a property results in a runtime error or other bug. If you're lucky, the invalid value causes the application to halt and display an error message to the user. It's much worse to have the application continue operating as if nothing is wrong when, in fact, the class module is working with invalid data. The best situation is when the class module itself validates property values as they're assigned, instead of waiting until the properties are used by forms, reports, and code in the application.

For example, consider a banking application that calculates exchange rates for foreign currency deposited in the bank's vault. A class module is the ideal vehicle for handling foreign currency exchange calculations. Keeping these calculations in a class module isolates these complicated routines from the rest of the application and makes it easy to maintain the calculations as currency values fluctuate. And, because class modules support IntelliSense, it's much easier to work with objects defined by class modules than public procedures stored in standard modules.

Ideally, the exchange rate class module wouldn't accept invalid exchange ratios or would check the exchange ratios that the user inputs at runtime. Perhaps the class module could check online sources such as The Wall Street Journal or other financial publications to verify that the data the user input is correct.

Property errors might occur if the code passes a string when a numeric value is required or when a property value is less than zero. The following strategies help bulletproof properties and avoid runtime errors:

• Set default property values if the code passes an inappropriate data type. Use a conversion routine to correct the value, if possible.
• Use private procedures in the class module to validate data types. These datavalidation routines are often class-specific
• Use error trapping everywhere in the class module, especially on the class's properties and methods. The property procedures and methods (the public procedures in the class) are where most unexpected behaviors occur.

Tip: Keep in mind that a basic principle of using object-oriented programming is encapsulating functionality. Whenever possible, you should include anything that affects how the class operates in the class module. Keeping the property validation, method error handling, and other features in the class module makes the class more portable and reusable.

Encapsulation isn't well implemented in the clsProduct1 example presented in this section. For example, the form's code retrieves the data, and assigns values to the product object's properties. A better approach would be to have all the data management performed by the class itself, isolating the form from the data-management operations. A form using a properly constructed class shouldn't have to know which database table contains the product data; instead, the form should be a strict consumer of the product data.