Last month we covered what the Properties, Events and Methods (PEMs) of an object are and how they might be used in Object Oriented software development. This month I want to cover how an object is defined and created.

All objects are defined as being based upon some type of base class definition. For example in Visual FoxPro there are base class definitions such as form, textbox, editbox, line, shape, custom just to name a few. All of these objects have predefined Properties, Events and Methods that are common among all objects. For example all of the objects posses an Init and Destroy event. These correlate to C++’s Constructor and Destructor. When an object is being created in memory to be used its Init method fires. When it is being removed from memory during program execution its Destroy method fires. If for example you wanted to set particular property values for the object, you would write code to set those values in the objects Init method. Then when the object was created the code in the Init method would run and the values would be set. The same holds true for the Destroy event. Different objects may also posses specific PEM’s that are particular only to that individual base class object. For example the textbox object has a Value property that holds the current value that is displayed on the screen in a text entry field such as a person’s name. But, the line or shape objects are just graphical objects and do not display a value on the screen and therefore they do not posses a Value property. However, all three objects have a Left, Top and Height property that defines the objects specific location on the screen.

These base class definitions may be confusing, but they are the basic building blocks of a software application. When you see separate windows on your screen, each of those windows was created from the basic Form object’s definition. Each and every text box that is displayed on that form were instantiated based upon the textbox object’s definition. It is the software developer’s job to write the code behind the objects to make them behave the way they want them to behave. For example when you enter your name into a textbox field on a form in a program and the program prompts you for your last name because it hasn’t been entered, the software developer had to place that code into the textbox’s Valid event to check for any special rules.

Object definitions can be subclassed and then modified to have new properties and/or methods to add new functionality or capabilities to the basic object. Subclassing can also allow you to override its Parent Class’s default behavior as well. A good example would be a telephone. When the telephone was first invented it didn’t support all of the whiz bang features of today’s modern phones. The very first phones had an earphone, a microphone and a ringer. This was the basic requirement of the telephone. As time progressed and new ideas came along new features were added to the telephone. It’s much simpler to start with the same basic design of the phone and add a new feature to it rather than redesign the entire phone from scratch. This holds true for software as well. Let’s say you’ve designed some software to perform a certain task. You’ve spent hours and hours testing it to make sure it performs its tasks correctly. It’s certainly quicker and less costly to make some minor changes to this tested software than rewriting it completely from scratch each time you add a new feature. Rather than copying all of the code from the tested software and modifying that, it is much easier to subclass the objects class definition and add new features to the subclassed object.

When an object is subclassed it inherits all of the Properties, Events and Methods of its Parent Class. For example if we subclassed the basic telephone, we would have a new definition of a telephone that has a microphone, earphone and a ringer. But let’s say that we want to now add a new feature to this basic phone such as a dialer. We could add new functionality by simply defining what the dialer does and enhancing the basic telephone. You know the basic phone already works. So just add on the dialer functionality and test it. Use the philosophy of, "If it isn’t broke don’t fix it!"

Now that you’ve defined your objects in code as a class definition, you can create or instantiate the object in memory. To instantiate an object in Visual FoxPro we use the CreateObject() function. We usually use a variable to reference the newly created object such as oMyObject = CreateObject(‘My Class Definition’). This new variable reference called oMyObject can now be used to reference the new object to call its Methods and set its Properties. Multiple objects can be instantiated from the same class definition. For example, you could say oMyObject2 = CreateObject(‘My Class Definition’) again to create another object in memory that has the same characteristics but stands all by itself and is completely independent of oMyObject. For example when multiple database fields are displayed on a data entry form, each of those textbox objects are instantiated based upon the same base class textbox object.

The class definition of an object includes all of its Properties, Events and Methods. This object-oriented concept that an object is completely self-contained is known as Encapsulation. That is, the object can contain both properties and methods within a single unit. When an another object or an outside program sees an object, it is only sees the object’s public interface. That is only those PEM’s that are made public. For example you would not want an outside source to know about all of the variables and properties that may be used internally for intermediate computational values. It would be damaging to the object if had its intermediate values being changed by an outside program without its knowledge. This is where hidden and protected properties and methods come into play. However, there is a way for an object to know when its Properties are being changed or read using the Access and Assign methods. We’ll discuss them more in our next article and how they can be used.

I hope these concepts haven’t been too confusing to understand. It does take time to digest these things, but the payoff can be reduced development time and more stable applications. There are hundreds of books on this subject and they typically vary between 500 to 1500 pages. Therefore, I’m hoping to provide a basic understanding to help you in getting started into the world of OOP development.