Basic and High-Level Classes
The DataFlex runtime has a series of built-in low-level classes, referred to as the basic classes. Examples of the basic classes are Form, Grid, Edit, and Array. These classes are built upon through a hierarchy of subclasses, eventually resulting in high-level classes. Examples of the high-level classes are dbForm, dbGrid, and DataDictionary. Any high-level class is part of a class hierarchy. For example, the hierarchy of the high-level class dbForm is:
While this is an accurate representation of the class structure, it verges on information overload. As application builders, we are going to look at our classes from a different perspective.
You write your programs using tools. There are two types of tools: basic and high-level. The basic classes you are most likely to use are:
ArrayFormEditRadio- CheckBox
Grid- List
- ComboForm
- SpinForm
- ModalPanel
- Group
- Panel
- Container3D
- Button
The high-level classes you will use are:
- dbContainer3D
- dbGroup
- dbView
dbForm- dbComboForm
- dbSpinForm
- dbEdit
dbGrid- dbList
- dbModalPanel
- DataDictionary
All of these classes are task-specific. When writing an application, find the tool that is best suited for the job and use it.
The Basic Classes
You can actually write some pretty sophisticated applications without using any basic class directly. At some point, however, you may need to use them. Then, you would need to know how.
Sometimes you will not need any of the high-level data-entry classes in your program. When you write reports, you will need selection panels to enable users to choose report printing selections (date ranges, output device, etc.). Trying to use the high-level classes to do this is like trying to split a toothpick with a power saw. You will find that the Container3D, Group, Form, Button, and Radio classes are ideally suited for this kind of task.
Sometimes you will find that you need to mix some base-class objects among your DEOs. You might want a view to contain a Close button. This can be easily done if you know how to use the base classes.
The High-Level Classes
Since you spend most of your time writing data-entry programs, you will spend most of your time using the high-level tools. It is easy to keep track of these tools, as each does a specific job. If your users need to enter text field data, you will need a text-editor DEO (dbEdit). If they need a data-entry form, you will need a form DEO (dbForm). If you use the standard DataFlex high-level tools, you use one set of tools (dbForm, dbGrid, etc.). You or your company might decide that you need to extend these tools one more level (dbForm_xyz, dbGrid_xyz, etc.). This gives your programs a unique look and feel that is consistent throughout your applications.
Tool building and application building are two separate processes. Before you can build your application, you must have a set of tools that will do the job. Depending on your needs, you will either purchase your tools, build your own tools, or purchase tools and extend them. Once you’ve got the tools you need, you can start application building. Hopefully, you will spend most of your time application building.
When you create classes, you are building tools. When you create objects, you are building applications.
From an OO-purist standpoint, this statement is not quite true. When you are creating an object, you will find that this object will require some custom functions and procedures. Whether those functions and procedures get placed in an object or a subclass, technically you are creating a subclass. Should this subclass be thought of as a reusable tool? Usually, it should not. The subclass tends to be so specialized that it will only ever be used by a single object. If you choose to place all functions and procedures in subclasses, you will find that you have a high-level tool class, many subclasses descended one level from this class, and a single object for each of these subclasses. The following diagram shows some entry-form objects used by the XYZ Company. This company has extended the class one more level.
In this example, the dbForm_xyz class is the reusable form data-entry tool. There will be many objects or subclasses based on this class. When application developers need to create an entry form, they will start with this class. This class has to be a good, generalized, robust tool.
The subclasses based on dbForm_xyz need not all be so reusable. They perform very specific tasks and tend to be used by only one object or application. It would make sense to combine these subclasses and their objects into a single entity. DataFlex allows you to do this by placing the subclass code inside the object. These are object/classes. We could restate our earlier rule to say:
When you create classes, you are building tools. When you create object/classes, you are building applications.
Using object/classes, our XYZ Company object structure changes as follows.
All of the objects (actually object/classes) are based on the dbForm_xyz class. Tool building now resides in one column and application building resides in another. You will notice that all of the samples provided show how to build applications. Most DataFlex programmers are application builders. If you want to see examples of tool building, look at the subclasses in the .pkg files.