When to Create Classes

When no existing class provides functionality close to what you need, or when multiple custom objects with similar definitions will be used in one or more applications, it is beneficial to create a class. There are three categories of class creation: generalized, application-specific, and program-specific.

Generalized Classes

Generalized classes are designed to be used in a variety of applications, without requiring the use of modules or classes oriented toward a specific application. All of the data-entry classes (lists, grids, entry forms) are examples of generalized classes.

Application-Specific Classes

Application-specific classes are designed to allow the creation of one or more specific objects in programs designed for a particular application. Data-server subclasses for each data file are an example of an application-specific class.

Program-Specific Classes

Program-specific classes are created and used in a single program (a single source-code module). The creation of program-specific classes is often a matter of programming style and preferences. Some programmers prefer to never create object/classes. An object/class is a class created internally by DataFlex when one or more functions, procedures, or property definitions not contained in the superclass is created in an object. Instead, these programmers create a subclass for any such object, moving all the customizations into the subclass. They then base their object on this subclass. Others are content to let DataFlex handle this, at least up to a point.

Determining Class Type

How do you know if a class should be generalized, application-specific, or program-specific? The answer is that you can't always tell before creating and using the class. You may find that what you thought was an application-specific class can be reused in other applications. You may find that what you considered to be a program-specific class will need to be reused in another program. You may discover that a generalized class is only ever used once, or never used at all. The truth of the matter is, there is really only one kind of class, and it is reusable.

While you may not be able to categorize a class type, you will find that the type of programming required for each class type is substantially different. The more generalized the class, the more generalized the code must be. In other words, such a class must be able to operate properly in many different conditions. For this reason, the design and creation of generalized classes takes more time. The data-entry classes are good examples of this generalized type of design.

Handling Messages in Generalized Classes

When a dbForm processes the request_save message, it must check to see if it is directly using a DSO, if it is using its parent’s DSO, or if it is not using any DSO at all. It must be able to handle each case. If you are creating a generalized subclass based on dbForm, you must make sure that it can also handle all of these conditions or specifically document any new limitations. Either way, this will take time.

If you were creating a dbForm subclass that is only going to be used in one specific module, you would not need to handle all possible variations because you could know the variations will not occur. If you build every class to be generalized and reusable, you will over-build, and the development process will be too slow. If you build every class as if it were program-specific, you will under-build, and you will find that none of your classes is reusable. Because you will not be able to reuse your classes, you will again find that your development process will be too slow.

Best Practices

The best solution is to know what type of class you are building and design accordingly. Another way to say this is to know when you are building tools and when you are building applications. This approach should yield the most efficient long-term development strategy. Keep in mind that it is not hard to convert a specific class into a more generalized class. In fact, it is not that hard to convert an object/class into a separate subclass and object.

Class Definition and Packaging

A class can be defined within the main source module of a program or in a separate source file called a package that allows the class definition to be reused by multiple modules. When creating a package, the source is stored in a file with the extension .PKG and can be included for use in a source module with the use command. Generalized and application-specific classes will almost always get placed in their own package files and included in source modules with a use command. Program-specific classes will often be coded directly in the module that uses them.