Getting the Most from Class Modules

To finish with, here are five closing thoughts to help you on your way when using objects and collections. It really is worthwhile getting to grips with class modules as they are a key part of Microsoft's programming strategy across all its development products.

Hide Your Data

Make sure that you declare everything privately unless you really want to expose it as a method or property of the class. Public variables act like properties, in that they can be inspected or set from outside the module. However, unlike properties - which have clearly defined Property Let and Property Get statements - there is no way of detecting when a public property is being set or inspected. As an aside, for troubleshooting purposes, a breakpoint can be set in the Property Let, which allows you to find out exactly when and from where the value is being set. So, if you want to expose something, use a property or a method to do so.

If you accidentally expose something you shouldn't, then several things could happen:

• Code outside your object might accidentally alter data within your object.

• This could cause your object to behave in a way other than how it should and can be a beast of a bug to track down.

• Procedures that use your objects may rely on those wrongly-exposed properties for their functionality.

• This makes maintenance a nightmare. You expect to have to check procedures that access your object when you modify your class's interface, but you don't want to have to check that they will still work whenever you modify the implementation as well.

• Bad values could be introduced, with no way for you to check or fix the values, or even discover who was setting the bad value.

Don't Overdo It

Although objects are useful in some situations, that's no reason for using them everywhere. Creating an instance of an object and invoking a method of that object not only consumes more memory than calling the function in a standard module, but is also more time-consuming . So use class modules judiciously.

Avoid Get and Set Methods

It is not good practice to create objects with lots of methods whose names begin with Get and Set . For example, we could have implemented a GetAccuracy and SetAccuracy method to allow developers to inspect and set the value of the accuracy to be used in the PaymentStats object. But if you want users of your objects to 'get' some form of information about of your object, then you should formally expose that information as a property, and if you want users to alter properties of your object, you should make those properties writeable .

Get the Object Model Right

It is easy to just wade in and create models without thinking through exactly what your object model should look like. But the same warning applies to designing objects that applies to designing databases: design time is the best time to design! If you have to redesign your object model halfway through the build process, the chances are that you will then have to change all the code that uses those objects. That's seldom cheap and it's never, ever fun.

Make it Look Easy

We mentioned earlier that one great advantage of using objects is that they offer the possibility of abstraction. In other words, the code inside the object might be quite complex, but the interface the object presents to users is very straightforward. Although it required knowledge of geometry to design the implementation of the Area property of the MyRectangle class, no such knowledge is required to use the property. The implementation might be complex, but the interface is easy. What's more, implementing polymorphism, through the use of the Shape interface class, meant that the MyShapelyRectangle and MyShapelyKite objects exposed identical properties and methods and so were easier to use. If you knew how to use one, you knew how to use the other.