Excel 2003 VBA Programmer's Reference

4

Object-Oriented Theory and VBA

A wise sage once said: divid et impera (divide and conquer). The original statement was probably made about an impending battle, as in, divide the enemy and conquer them by divisions. Interestingly enough, this advice is apropos of the way we can conquer software engineering problems. We can divide the problem into many smaller, discrete problems and conquer them individually, or we can permit the problem to divide our attentions and the problem will conquer us.

A well-considered rule of thumb is to organize a solution by addressing the most complex and critical problems first. Generally, these challenging pieces act as a forcing function for significant portions of the solution, and an application without these critical pieces would be considered incomplete.

This chapter is about the mechanism that supports dividing and conquering a problem, the class. In Chapter 5 you will learn about general object-oriented theory and how this theory is supported in Visual Basic for Applications.

Comparing Classes and Interfaces

General object-oriented theory supports two common means of describing something. The first is the class. Classes are typically used to describe entities in the solution domain. A low-tech way of thinking about classes is that a class is used to nouns that are important to the problem's solution. A common analogy is that a class is a blueprint and an object is an example of the thing that the blueprint describes. The second descriptive ...