Try OpenEdge Now
skip to main content
Object-oriented Programming
Getting Started with Classes, Interfaces, and Objects : Defining classes
 

Defining classes

Classes encapsulate state and behavior. Defining a class requires a mechanism to define the set of data members and properties that represent the class's state and a set of related methods and events that provide the behavior of the class. The members of a class comprise the type of the object defined by the class. As with other data types, the compiler verifies that references to a class and its members are consistent with its type. Another object type is an interface, which also has members, and provides a means to enforce a consistent definition for the corresponding members of similar class types. (For more information on defining interface types, see Defining interfaces.) Class-based objects are running instances of classes. At run time there can be many instances of a class, each with its own state. There can also be object references of different types pointing to a single class instance that represents all these types. A valid reference type can be a class in its class hierarchy or an interface that it implements. For more information on how an object can represent more than one type, see Designing Objects: Inheritance, Polymorphism, and Delegation.
After beginning a class definition with a CLASS statement, which specifies the class type and its relationship to any other class and interface types, you can define a user-defined class with the following types of elements:
*Data members and property members that define the state of the class
*Method and event members that define the behavior of the class, including special methods (accessors) associated with properties
*Optional constructors, which are special methods that are invoked when the class is instantiated
*One optional destructor, which is a special method that is invoked only when the object is destroyed
*Class-scoped handle-based objects that are not class members, but which can be referenced in the class, including static ABL widgets, streams, and work tables
*ON statements that are also not class members, which are used to define triggers for events on ABL widgets and other supported handle-based objects that are referenced in the class
*User-defined function prototypes, also not class members, which are used to specify user-defined functions in external procedures that are referenced in the class
Together with the CLASS statement, all of these elements provide the mechanisms for defining classes as described in the following sections:
*Defining state in a class
*Defining behavior in a class
*Defining classes based on other classes
* Defining state in a class
* Defining behavior in a class
* Defining classes based on other classes