Class-based objects support a programming model where you design and instantiate objects based on strongly-typed classes. Like procedure objects, classes maintain a run-time context that can be accessed by other objects. For class-based objects, this context also can include various types of data (data members and properties), but instead of internal procedures, user-defined functions, and named events, a class-based object’s behavior is provided by methods and class events. Thus, a class-based method is a unit of executable code that has features in common with both internal procedures and user-defined functions, as well as features unique to methods.
A class event is a mechanism similar to a named event that allows you to send notification of a particular condition that an application can respond to in different ways. A data member is a variable, buffer, temp-table, or similar data element that is defined for a class at the same level as its methods. A class-based property is similar to a variable data member, but its access can be further controlled by specifying if it is readable, writable, or both and defining any behavior to be invoked when the property is read or written. Each method, class event, data member, and property defined within a class is a member of that class, and the members defined for a class collectively contribute to the type definition of that class.
Note: Class-based methods are analogous to, but entirely different from the built-in methods that ABL provides on handle-based objects, such as procedure, buffer, and query objects (among others). The main difference is that class-based methods can be user defined, and they are strongly typed to the classes in which they are defined.
With class-based objects, the state and behavior in one object has a well-defined (strongly typed) relationship to the state and behavior in another class-based object. You establish these relationships at compile time by using syntax designed to associate class-based objects with each other in a well-defined hierarchy that allows objects to share class members that are defined in other objects. As a result, you can organize class-based objects with well defined interfaces before you even compile the objects.
If you change the interface or relationship between the objects, many errors can be caught at compile-time that might not be caught for some time using procedure objects at run time. Because relationships among class-based objects can be defined at compile-time, ABL also supports standard management features for creating and deleting (destroying) these objects in a consistent and less error-prone manner. When you access state or behavior in other class-based objects, you can have greater confidence that this access is both permissible and appropriate for your designed task.
Classes can also be abstract. An abstract class can have much the same definition as a non-abstract class, except that it can define abstract methods, properties, and events. Abstract members of a class are really prototypes for members that an inheriting class must implement. You also cannot create instances of an abstract class, whether or not it defines abstract members for implementation by an inheriting class. Thus, an abstract class allows you to define and manage common state and behavior like any class, but also requires one or more inheriting classes to complete its functionality in a unique way.
Note that an interface type (previously described) can also provide prototypes for methods, properties, and events that a class must implement. However, the difference is that an abstract class provides some implementation that an inheriting class must complete, while an interface provides no implementation that an implementing class must provide. In practice, an interface typically defines members that represent some discrete functionality that is not necessarily related to other features of a class that implements it (for example, properties and methods intended to implement a list structure or collection). An abstract class typically defines abstract members that are related to the overall class functionality that requires some customization by an inheriting class.
The choice of whether to use interface types or abstract class types to define class interfaces is a design decision for any object-oriented application.
