Classes and Objects
Standard object theory states that classes contain methods, while objects are instances of these classes. In DataFlex terms, this implies that classes should contain functions, procedures, and property definitions, whereas objects should only contain data. In other words, an object should be an instance of a class, made unique by the values of its properties.
Object Interaction
What can your program do with an object? It can:
- Create it
- Send messages to it
- Destroy it
Sometimes sending a message to an object will change a piece of its data (e.g., Set value to "John"). Other times, sending a message will cause an action to occur (e.g., Send RingTheBell). In all cases, messages sent to an object are handled by the object's class. The code that makes a message do something is contained in the class, not the object. The data that is acted upon or changed is in the object, not the class.
Message inheritance occurs at the class level. When a message is sent to an object, the object refers the message to its class definition. If the class can resolve the message, it will; if it cannot, it will forward the message up the class tree. Inheritance is a class concept, not an object concept.
Object-Oriented Programming Principles
Classes contain procedures, functions, and property definitions, while objects contain data. This is a fundamental principle of object-oriented programming. The above statement might appear inconsistent with the reality of DataFlex. Nearly every sample program included here contains objects with functions and procedures. Is DataFlex breaking the rules? No, it is taking a shortcut that makes the product easier to use (this is a human-engineering shortcut).
When you place a function or a procedure (or define a property) in an object, you are creating an "object/class." DataFlex cannot actually create an object with functions or procedures not defined in the object’s declared class. Instead, DataFlex will define a new "secret" subclass that contains all of the object's functions, procedures, and property definitions. It then creates the actual object as an instance of this new subclass. This shortcut allows you to create a subclass and an object in one piece of code. For example, the following two samples yield the same result:
// An example of defining a new subclass
// and creating an instance of that class:
Class cBigBell is a cObject
Procedure RingTheBell
Send Bell
Send Bell
Send Bell
end_procedure
end_class
Object oMyBell is a cBigBell
end_object
// An example of creating an object/class:
Object oMyBell is a cObject
Procedure RingTheBell
Send Bell
Send Bell
Send Bell
end_procedure
end_object
Considerations of Object/Class Shortcuts
Shortcuts usually have a hidden cost. The object/class shortcut is no exception. When you create an object/class, DataFlex will define a new subclass and an instance of that class. That one object instance is the only object that you can base on that class. In the first example above, we could create as many instances of the cBigBell class as we desire. If we were using the object/class method, we would have to create additional object/classes, each containing the same procedure. This is wasteful and a bad programming practice.
- Subclasses are reusable (you can create multiple instances of it).
- Object/classes are not reusable (one hidden subclass, one object).
Creating object/classes has advantages. Very often, you will need to customize a class to create a single instance of this class. The special entering or exiting procedures you code in an entry form might only ever be used to create a single object instance. Not only is it easier to code this into an object/class, but it is probably easier to read. This is especially true when functions and procedures are created to handle the interaction between objects. It is much easier to see what is happening if all your code is together.
Some developers have chosen not to place any functions, procedures, or property definitions inside objects. Instead, they create many subclasses. This is the purist approach. Other developers have chosen to create object/classes, feeling that the ease of use outweighs the disadvantages. The Framework methodology supports either style. The samples shown here use the object/class method because it is more consistent with the style that has predominated to date.