Interface (object orientation)

An interface ( English interface ) are in the object-oriented programming to which methods in different classes are present or must be present.

Technical details

An interface indicates which methods are available or must be available. In addition to this syntactic definition, a so-called contract should be defined on the meaning ( semantics ). Established as preconditions and postconditions of the various methods The contract is usually only set informally in the documentation or an external specification of the interface. There are also formal specification languages such as B. the OCL is available. Some programming languages such as B. Eiffel also offer direct syntactic possibilities for defining a contract.

Interfaces represent a guarantee of the methods available in a class. They indicate that all objects that have this interface can be treated equally.

In some programming languages that do not support multiple inheritance (such as Java ), interfaces can be used to define compatibilities between classes that do not inherit from each other: the interface relationships are not tied to the strict class tree. For this purpose, interface declarations are often explicitly marked as such (for example with the keyword interface ). However, interfaces are not suitable as a substitute for multiple inheritance, as they only define methods and their parameters and do not allow functionality to be inherited.

declaration

Other languages (mostly those that support multiple inheritance, such as C ++ ) know the concept of interfaces, but treat them like ordinary classes. One then speaks of abstract classes . Sometimes a separate language (a so-called interface description language , IDL) is used to declare the interface - this is usually the case with middleware systems such as CORBA or DCOM . Object-based languages without strict typing usually have no interfaces.

Definition of constants

In some programming languages such as Java or PHP it is possible to declare constants within an interface definition. These constants are then available to all implementing classes.

Classification of interfaces

Interfaces can be classified according to two independent criteria: generality and benefit. With regard to generality, a distinction is made between general and context-specific interfaces, and with regard to benefits between offering and enabling interfaces.

General interfaces contain the entire public interface of the called party. They are used to separate the interface specification used from its implementation.
Context- specific interfaces do not cover the entire public interface of a class, but only special aspects of this class. They allow objects of a class to be used in special roles. For example, a buffer can be used for reading or writing. A separate interface can exist for each of these access "aspects".

Offering interfaces are present when the caller addresses the called party via the interface. This is the typical and most common case when using interfaces.

Enabling interfaces exist when, conversely, the called party or even a third component is the actual beneficiary of the interface. For example, an object (or its class) can Printableimplement the interface . Such an object can then be given to one Printerfor printing. Obviously, the object that fulfills the interface does not provide the service here, rather it only enables it.

A special case are so-called marking interfaces that do not require any methods and are evaluated at runtime using introspection mechanisms .

Example of an interface

For example, if there is an interface Kontowith the method abbuchen(), all classes that implement this interface must have a method abbuchen. Another example: A number of classes with the names SparKonto, GiroKontoand DepotKontoimplement the interface Konto. The interface has a method getKontostand, so all classes with the interface must getKontostandprovide the method .

If several interfaces are implemented in a class and their methods have the same name and the same signature (parameter type and return type), access and implementation must take place in a class with a qualified name; H. by prefixing the package name ( Java ) or the namespace ( .NET ). An example in Java:

public interface Konto {
    int getKontostand(); // abstrakte Signatur-Definition
}

public class SparKonto implements Konto {
    private int kontostand;
    // Implementierung der durch Konto definierten Methode
    public int getKontostand() {
        return kontostand;
    }
    …
}

Java differs from .NET languages in another respect in that a class that implements an interface does not have to be explicitly declared. The following example defines what is known as an anonymous inner class within a method.

public Konto erstelleKonto()
{
    return new Konto() { //Beginn der anonymen inneren Klasse
        // Implementierung der durch Konto definierten Methode
        public int getKontostand() { 
            return 0;
        }
    }; //Ende der anonymen inneren Klasse
}

Naming conventions

In some programming languages it is common to make interfaces recognizable by special prefixes or suffixes ( Hungarian notation ). Often an “I” (for interface ) is prefixed or an “IF” or “interface” is appended. The example Kontointerface given above would then be called IKonto, KontoInterfaceor KontoIF.

advantages

Interfaces can be recognized as such by their name.
Implementing classes can have a simpler name.

disadvantage

Interfaces should not be recognized as such by their name, since as a user of other objects one should only consider their interface (i.e. public methods).
Interfaces can be seen as the essential element of programming. It therefore makes more sense to add prefixes or suffixes to the names of the implementations.
Interfaces are particularly useful when there is more than one implementation, so that the implementing classes are named with prefixes and suffixes anyway.

Individual evidence

↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software . Addison-Wesley, 1995, ISBN 0-201-63361-2 , page 18

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software . Addison-Wesley, 1995, ISBN 0-201-63361-2 , page 18