INTERFACE statement
Defines a user-defined interface. An interface defined with this statement represents a user-defined data type that defines a set of method, property, and event prototypes for methods, properties, and events that can be implemented by one or more classes. Any class that implements the interface must support all the methods, properties, and events whose prototypes are defined in the interface.
You cannot instantiate an interface as an object. You can only use it to define the specified interface for a class (which you can instantiate) that implements the interface.
Note: This statement is applicable only when used in a class definition (.cls
) file. For more information, see the Notes section in this reference entry.Syntax
interface-type-name
Defines the type name for a user-defined interface type. Specify an ABL interface type name as described in the Type-name syntax reference entry. You can also specify an unqualified interface name (without a package), but only if the interface name represents the full type name for the interface (that is, the interface is not defined as part of a package).Note that you cannot specify "Progress" as the first component of the package name for any ABL user-defined interface. For example, "Progress.Inventory.IUpdateInv" is an invalid type name for a user-defined interface and results in a compiler error.interface-body
The body of an interface definition is composed of the following types of elements:
- Temp-table or ProDataSet object definitions used as parameters by one or more methods whose prototype is declared in this interface
- Method prototypes for common methods implemented by one or more classes
- Property prototypes for common properties implemented by one or more classes
- Event prototypes for common events implemented by one or more classes
Define elements in the interface body using the following syntax:
temp-table
|dataset
Specifies one or more temp-table or ProDataSet object definitions used as parameters by one or more methods declared in this interface. You must specify these object definitions before any method prototypes. The AVM does not allocate memory for these object definitions. You cannot specify an access mode for these object definitions.The definition of temp-table and ProDataSet object parameters for methods defined in any classes that implement this interface must match the temp-table or ProDataSet object definitions in this interface.For temp-table objects:
- The temp-tables must have the same number of fields, and each field must match with respect to the data type, extent, and position. Neither the table names nor field names must match.
- The temp-tables must have the same number of indexes, and each index component must match, including the index names. However, the index-component field names do not need to match.
For ProDataSet objects:method-prototypes
Declares one or more method prototypes in the interface. A method prototype declares a method of a class without an implementation (that is, without specifying the method’s logic or the END METHOD statement).For information on the syntax formethod-prototype
, see the METHOD statement reference entry for declaring method prototypes. Note the following:The implementation of these method prototypes, in classes that implement this interface, must not include the STATIC option and must match these declarations with respect to:property-prototypes
Declares one or more property prototypes in the interface. A property prototype declares a property of a class without implementing its GET or SET accessors (that is, without specifying the property’s logic). You must specify a property prototype with a PUBLIC access mode. The property prototype must include either a GET and SET accessor, or a GET accessor, or a SET accessor. Although the property declaration cannot have accessor implementations, the property when implemented in a class may include an accessor implementation.For information on the syntax forproperty-prototype
, see the DEFINE PROPERTY statement reference entry for declaring property prototypes. Note the following:The implementation of the property, in classes that implement this interface, must not include the STATIC option and must match these declarations with respect to:
- Access mode, which must be PUBLIC
- Name
- Data type or type name
- EXTENT — Its presence or absence, determinate or indeterminate, and size (if determinate)
- Accessors — Any accessor appearing in the interface, plus the option of any additional accessor not specified in the interface, all defaulting to PUBLIC access mode
- Presence or absence of NO-UNDO
event-prototypes
Declares one or more event prototypes in the interface. An event prototype declares a class event that the class must implement with an identical declaration, allowing the class to publish the event.For information on the syntax forevent-prototype
, see the DEFINE EVENT statement reference entry for declaring class event prototypes. Note the following:The implementation of these event prototypes, in classes that implement this interface, must not include the STATIC option and must match these declarations with respect to:END [ INTERFACE ]ExamplesThe following samples include two different class definitions that provide similar functionality, but in distinctly different ways. Each class implements the same interface and both classes define a ProDataSet data member (
dsHighCustData
) used to retrieveCustomer
and relatedInvoice
table data for a singleCustomer
record from thesports2000
database. However, each class selects theCustomer
record using a different and functionally distinct algorithm provided in its own implementation of the same interface method prototype.Thus, each of the following sample class files implements the
r-ICustObj
interface type defined in the class definition file,r-ICustObj.cls
and provides the following functionality:
r-ICustObjImpl.cls
— Defines ther-ICustObjImpl
class, which retrieves data from the singleCustomer
and relatedInvoice
records that contain the highest balance value represented by theCustomer.Balance
value. This functionality is almost identical to what is provided by ther-CustObj.cls
sample class file that is fully described in the Examples section of the CLASS statement reference entry. (The main differences from ther-ICustObjImpl
class are that ther-CustObj
class does not implement an interface type and it is defined as FINAL.)r-ICustObjImpl2.cls
— Defines ther-ICustObjImpl2
class, which also retrieves data from a singleCustomer
and relatedInvoice
records. However, this class retrieves data for theCustomer
whose relatedInvoice
records contain the highestInvoice
balance represented by the sum of theirInvoice.Amount
values.Following is the interface definition provided by the sample
r-ICustObj.cls
file.
The implementations of the
SetHighCustomerData( )
method populate the ProDataSet with selected fields fromCustomer
andInvoice
records, where the selectedCustomer
also has related invoices. Each implementation ofSetHighCustomerData( )
also sets the two implemented properties (HighCustBalance
andHighCustNum
) to appropriate values for the selectedCustomer
, and publishes the implemented class event (CustHasInvoices
) for eachCustomer
record it encounters with relatedInvoice
records. Each class defines additional data members to support its instance of the ProDataSet, and also must implement theGetHighCustomerData( )
method (according to the interface) to pass the ProDataSet as a by-reference output parameter.Following is the interface implementation provided by the
r-ICustObjImpl
sample class. Note that the property implementations add initial values, but rely on default behavior for the accessors. The class also fully defines the ProDataSet to be passed as a by-reference method output parameter.
The bold code inside the
SetHighCustomerData( )
method shows the difference in implementation from the same method implemented by the followingr-ICustObjImpl2
sample class. Here, it relies on the stored value of theCustomer.Balance
field to determine eachCustomer
balance and assigns theHighCustBalance
andHighCustNum
property values accordingly.The following
r-ICustObjProc.p
sample procedure shows an application of ther-ICustObjImpl
class, which responds to theCustHasInvoices
class event and displays the contents of thedsHighCustCata
ProDataSet. Note that it defines a reference-only instance of the ProDataSet as required by the class and its interface. (This application is identical to ther-CustObjProc.p
sample procedure described in the Examples section of the CLASS statement, but which instantiates ther-CustObj
sample class instead.)
Following is the interface implementation provided by the
r-ICustObjImpl2
sample class. This implementation is identical tor-ICustObjImpl
except for theSetHighCustomerData( )
method.
The bold code inside the
SetHighCustomerData( )
method shows the difference in implementation from the same method implemented by the previousr-ICustObjImpl
sample class. Here, it calculates theCustomer
balance from the total ofInvoice.Amount
values in its relatedInvoice
records and assigns theHighCustBalance
andHighCustNum
property values accordingly.The following
r-ICustObjProc2.p
sample procedure shows an application of ther-ICustObjImpl2
class, which is very similar to the previous procedure,r-ICustObjProc.p
. The differences include displaying both the storedCustomer.Balance
value and theInvoice.Amount
total for the selectedCustomer
record, as well as some cosmetic changes to the display. Otherwise, the application is identical.
Notes
- You can terminate an INTERFACE statement with either a period (.) or a colon (:), but typically use a colon (:).
- A class definition (
.cls
) file can contain only one interface definition that is optionally preceded by one or more USING statements. The complete interface definition must begin with the INTERFACE statement and end with the END statement, and the INTERFACE statement must be the first compileable statement after any USING statements in the file. A class definition file containing an interface definition cannot also contain a class definition.- The access mode for an interface definition is always PUBLIC.
- The compiled version of an interface definition file is an r-code (
.r
) file. For more information, see the COMPILE statement reference entry.- You can define an object reference variable for an interface, which lets you reference a class that implements the interface, but you cannot create an instance of an interface with the NEW function (classes). For more information on object references, see the AS CLASS option in the DEFINE VARIABLE statement reference entry and see the Class-based object reference reference entry.
- You can reference include files from within an interface definition. For more information about include files, see the { } Include file reference entry.
- All built-in preprocessor directives are supported in interface definitions.
- All built-in preprocessor names are supported in interface definitions. For a list of preprocessor name, see the { } Preprocessor name reference entry.
- You cannot pass compile-time arguments to interface definition files. However, you can pass compile-time arguments to include files referenced in an interface definition file.
- You can store class definition r-code files in ABL procedure libraries. If ABL encounters a procedure library on
PROPATH
, it will search the library for the specified r-code. However, you cannot execute r-code files stored in a procedure library that is not onPROPATH
using theprocedure-library-path
<<member-name
>> syntax.- While a property interface declaration may include a GET and SET accessor, or a GET accessor, or a SET accessor, you cannot force the property to NOT have a particular accessor in an implementing class. However, you can force the accessor to be missing when an instance of the class is used through an interface reference. You can do this by omitting the accessor in the property interface definition. Even though the accessor might be implemented in the class property, it will appear, when used through an interface reference, that the accessor implementation does not exist.
See alsoClass-based object reference, CLASS statement, DEFINE DATASET statement, DEFINE EVENT statement, DEFINE PROPERTY statement, DEFINE TEMP-TABLE statement, METHOD statement, Type-name syntax, USING statement
OpenEdge Release 10.2B
|