Classes are supported by a number of specific constructs within the language. First and foremost is the CLASS statement, which can be used to define a user-defined type (new object type) in ABL. ABL also provides a set of built-in classes for various features. Classes defined by the CLASS statement contain both state and behavior.

ABL class definitions support inheritance of state and behavior from one class to another. That is, you can define a new class with reference to an existing class so that the state and behavior of the existing class appear to be part of the new class. At the same time, you can define additional state and behavior in the new class that does not exist in the inherited class. Thus, multiple classes can be related to one another in a hierarchy formed by their defined inheritance relationships. For more information on inheritance, see Inheritance .

Classes can also implement one or more interfaces, each of which you can define using an INTERFACE statement. This statement also defines a user-defined type in ABL. An interface declares a common public mechanism for accessing state and behavior that one or more classes can define and that these classes might not inherit from another common class. Interfaces allow you to more easily define and manage common state and behavior that might be implemented differently in different classes and for different purposes. An interface can also be defined to inherit one or more interfaces. This composes the interface from the definitions of previously defined interfaces, but is not otherwise similar to class inheritance.

In addition to allowing you to define your own interfaces using the INTERFACE statement, ABL provides built-in interfaces to manage common state and behavior for some of its built-in classes. Like a class, an interface also represents an object type, but never contains an implementation of that type. Only a class can implement the type specified by an interface.

Thus, a class type or interface type represents a data type that you can specify in the language anywhere that a built-in data type (such as INTEGER) can be specified. In this way, the support for classes and interfaces in ABL is very similar to classes and interfaces in Java and other object-oriented programming languages.

Any given ABL object built from classes and interfaces can be seen as more than one type, depending on the hierarchy of classes and interfaces used to define the object. In other words, each class or interface type that you use to construct an object provides a different type through which you can access the object. Any consumer of the object only needs to access the object as a supported class or interface type in order to use the functionality supported by that type. Thus, depending on the type you use to access the object, the same object can provide different subsets of its total functionality.

A single CLASS or INTERFACE statement identifies a source code file that contains a class or interface definition and not the definition of an ABL procedure. Within a class or interface definition, there are several language statements that are distinctive to classes or interfaces (respectively) and which can only be used within them. On the other hand, you can use the vast majority of ABL syntax within classes, and for the most part, you can use them in exactly the same way as they are used in procedures.

This means that there is a dichotomy in how you must think about classes and procedures in ABL. On the one hand, there is a clear and absolute distinction between classes and procedures, and the compiler can tell from the presence of a CLASS or INTERFACE statement in a source file which kind of object it is dealing with. On the other hand, the majority of the programming that you do within a class can be much the same as within a procedure. This means that if you are already thoroughly familiar with how to program ABL procedures, programming with classes can quickly become as familiar and natural.