EGL uses the term "interface" in the same way as object-oriented
languages do. For EGL, an interface defines a plan for a service to
follow. Specifically, an interface contains one or more function
prototypes,
or summaries of functions. These prototypes are not usable functions
themselves, but they set out plans for the real functions.
For
example, suppose you needed to write an application that performed
mathematical operations like a calculator. You might start by listing
all of the mathematical operations your application would need (such
as addition, subtraction, and multiplication), without actually writing
the code to perform these operations. In this case, you would name
each operation and specify each operation's input and output parameters,
but you would not start coding any logic. In this way, you would be
listing the functions that the EGL service application would need
in an interface. Such an interface might begin like this:
interface myCalculatorInterface
//Function to add numbers together
function addNumbers(number1 decimal(10,2) in,
number2 decimal(10,2) in) returns (decimal(10,2));
//Function to subtract numbers
function subtractNumbers(number1 decimal(10,2) in,
number2 decimal(10,2) in) returns (decimal(10,2));
end
Then, when you are ready to begin coding the
service, you can use this interface both as a starting point and as
a test to make sure you are following your plan.
You will rarely
be required to write an interface, but in general, using interfaces
to describe your services is good programming practice:
- The interface lets you plan the service ahead of time, and EGL
warns you if the service deviates from the interface.
- Interfaces provide a concise summary of a service, explaining
what the service can do without providing all of the details of the
service's implementation.
- Interfaces can serve as requirements for development or compliance.