Classes in Visual FoxPro
All of the properties, events, and methods for an object are specified in the class definition. In addition, classes have the following characteristics that make them especially useful for creating reusable, easily maintained code:
- Encapsulation
- Subclasses
- Inheritance
Hiding Unnecessary Complexity
When you include a phone in your office, you probably don't care how the phone internally receives a call, initiates or terminates connections to electronic switchboards, or translates key presses into electronic signals. All you need to know is that you can lift the receiver, dial the appropriate numbers, and talk to the person you want to talk to. The complexity of making that connection is hidden. The benefit of being able to ignore the inner details of an object so you can focus on the aspects of the object you need to use is called abstraction.
Encapsulation, which involves packaging method and property code together in an object, contributes to abstraction. For example, the properties that determine the items in a list box and the code that executes when you choose an item in the list can be encapsulated in a single control that you add to a form.
Leveraging the Power of Existing Classes
A subclass can have all the functionality of an existing class, plus any additional controls or functionality you want to give it. If your class is a basic telephone, you can have subclasses that have all the functionality of the original telephone and any specialized features you want to give them.
Subclassing is one way to decrease the amount of code you have to write. Start with the definition of an object that is close to what you want, and customize it.
Streamlining Code Maintenance
With inheritance, if you make a change to a class, that change is reflected in all subclasses based on the class. This automatic update saves you time and effort. For example, if a phone manufacturer wanted to change from dial to push-button style phones, it would save a lot of work to be able to make the change to the master schematic and have all previously manufactured phones based on that master schematic automatically inherit this new feature, rather than having to add the new feature to all the existing phones individually.
Inheritance doesn't work with hardware, but you do have this capability in software. If you discover a bug in your class, instead of having to go to each subclass and change the code, you fix it once in the class and the change propagates throughout all subclasses of the class.
Containers and Non-Containers
The two primary types of Visual FoxPro classes, and by extension Visual FoxPro objects, are container classes and control classes.
Container Classes
Containers can contain other objects and allow access to the objects contained within them. For example, if you create a container class that consists of two list boxes and two command buttons, and then add an object based on this class to a form, each individual object can be manipulated at run time and design time. You can easily change the positions of the list boxes or the captions of the command buttons. You can also add objects to the control at design time; for example, you can add labels to identify the list boxes.
The following table lists what each container class can contain:
Container | Can contain |
---|---|
Command button groups | Command buttons |
Container | Any controls |
Control | Any controls |
Custom | Any controls, data environment, page frame, container, custom |
DataEnvironment | Cursor, Relation, and CursorAdapter objects |
Form sets | Forms, toolbars |
Forms | Page frames, data environment, any controls, containers, custom |
Grid columns | Headers and any objects except form sets, forms, toolbars, timers, and other columns |
Grids | Grid columns |
Option button groups | Option buttons |
Page frames | Pages |
Pages | Any controls, containers, custom |
Project | Files, servers |
Toolbars | Any controls, page frame, container |
Control Classes
Control classes are more completely encapsulated than container classes are, but can be less flexible for that reason. Control classes do not have an AddObject method.
See Also
Object-Oriented Programming | Classes and Objects: The Building Blocks of Applications | Preparation for Class Creation | Creating Classes | Modifying a Class Definition | Subclassing a Class Definition | Operating the Class Designer | Class Member Protection and Hiding | Specifying Design-Time Appearance for a Class | Creating, Copying, and Removing Class Library Files | Adding Classes to Forms | Default Property Setting Override | Container Hierarchy Object Referencing | Setting Properties | Calling Methods | Event Response