INTERFACES :
In ABAP Objects, interfaces are implemented in addition to and independently of classes. Interfaces exclusively describe the external point of contact of a class, but they do not contain their own implementation part.
Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task. The user never actually knows the providers, but communicates with them through the interface. In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required (this is polymorphism using interfaces).
The above example shows two users: the document library and the file browser. Both define the tasks that potential providers must be able to carry out: display and print in the first case and show a node for the file folder display in the second. Various providers (plain text files, spreadsheets) can perform all the services required, but one provider (the folder) can only perform the service required by the File Browser and can therefore not be used by the Document Library.
In UML, interfaces can represented in the same way as classes. However, they always have stereotype «interface» above their name and can therefore be told apart from classes.
The use of an interface is represented by a dotted line with a two-sided arrow from the user to the interface, the stereotype «uses» is optional. The fact that a class implements an interface is represented by a dotted line with a three-sided arrow from the class to the interface.
The similarity to the representation of inheritance is intentional, as the interface can be seen as a generalization of the class implemented or the class can be seen as a specialization of the interface.
In ABAP Objects, the same components can be defined in interfaces and in classes. This allows you to shift part of the public point of contact of a class into an interface, even though the class is already in use; users will not notice the difference as long as you use alias names (see appendix) for the components that are now in the interface.
A class can implement any number of interfaces and an interface can be implemented by any number of classes.
In ABAP Objects, the same components (attributes, methods, constants, types, alias names) can be defined in an interface in largely the same way as in classes. However, interfaces do not have component visibility sections.
Interfaces are implemented in classes.
The interface name is listed in the definition part of the class. Interfaces can only be implemented ‘publicly’ and are therefore always in the PUBLIC SECTION (this is only valid as of Release 4.6). If you do not do this, you risk multiple implementations, if a superclass and a subclass both implement the same interface privately.
The operations defined in the interface are implemented as methods of a class. A check is carried out to ensure that all the methods defined in the interfaces are actually present in the implementation part of the class (for global interfaces, a missing or superfluous implementation of an interface method results in a ToDo warning).
The attributes, events, constants and types defined in the interface are automatically available to the class carrying out the implementation.
Interface components are addressed in the class carrying out the implementation by prefixing the interface name, followed by a tilde (the Interface Resolution Operator):~.
The interface resolution operator enables you to access interface components using In object reference belonging to the class implementing the interface in exactly the same way as the method definition in the implementation part of the class.
This allows you to differentiate between components defined in the interface and components of the same name that are defined in the class itself. This is caused by the shared namespace.
Interfaces are addressed using interface references. Interface references always refer to instances in the classes carrying out the implementation. Interface references therefore always have both static and dynamic types.
The assignment of an object reference to an interface reference is known as a narrowing cast since, as with inheritance, only a part of the object interface is visible once you have assigned the reference.
With an interface reference, you can no longer address all components in the class carrying out the implementation, but only the components defined in the interface. These components are now addressed using the interface reference exclusively with their own ‘short’ name!
When an object reference is assigned to an interface reference, the static types Must be convertible, that is, the class that was used to define the object reference must have implemented the interface-reference interface. Otherwise there will be a syntax error.
The widening cast is, as with inheritance, the opposite of the narrowing cast: here it is used to retrieve an object reference from an interface reference. Obviously it cannot be statically checked, since an interface can be implemented by more than one class.
An object reference cannot be assigned to an interface reference if it has itself not implemented the corresponding interface. It cannot be assigned even if a subclass has implemented the interface and the interface reference points to an object in this class.
Assignments between interface references whose interfaces are not related to each other cannot be checked statically and must therefore be formulated using the cast operator “?=”.
For this type of assignment, a check must be carried out at runtime to see whether the class of the instance that the source reference points to also supports the interface that the target reference refers to. If this is the case, the cast is carried out, otherwise the catchable runtime MOVE_CAST_ERROR occurs.
This type of cast is neither a widening nor a narrowing cast, rather a switch from one view of an object to another.
Polymorphism can also be used for interfaces: you can use interface references to call methods that can have a different implementation depending on the object behind the reference.
The dynamic type, not the static type of the reference variable is used to search for the implementation of a method. CALL METHOD document->display above therefore uses the class of the instance that document actually refers to to search for the implementation of display. The static type for document, which is always ‘REF TO lif_doc’ is not used.
If you want to write polymorphic programs, you must first decide how the objects that you want to work with are related to each other. If the objects are dependent on each other through inheritance, then choose polymorphism and inheritance. However, if the objects are not directly related to each other, but simply ‘happen’ to have the same characteristics, then use interfaces to achieve polymorphism.
RELATED LINKS
OOPS ABAP 12
CRM Sales Cycle Management
CRM Sales opportunity management
Sales process in Quotation and order management in CRM
In ABAP Objects, interfaces are implemented in addition to and independently of classes. Interfaces exclusively describe the external point of contact of a class, but they do not contain their own implementation part.
Interfaces are usually defined by a user. The user describes in the interface which services (technical and semantic) it needs in order to carry out a task. The user never actually knows the providers, but communicates with them through the interface. In this way the user is protected from actual implementations and can work in the same way with different classes/objects, as long as they provide the services required (this is polymorphism using interfaces).
The above example shows two users: the document library and the file browser. Both define the tasks that potential providers must be able to carry out: display and print in the first case and show a node for the file folder display in the second. Various providers (plain text files, spreadsheets) can perform all the services required, but one provider (the folder) can only perform the service required by the File Browser and can therefore not be used by the Document Library.
In UML, interfaces can represented in the same way as classes. However, they always have stereotype «interface» above their name and can therefore be told apart from classes.
The use of an interface is represented by a dotted line with a two-sided arrow from the user to the interface, the stereotype «uses» is optional. The fact that a class implements an interface is represented by a dotted line with a three-sided arrow from the class to the interface.
The similarity to the representation of inheritance is intentional, as the interface can be seen as a generalization of the class implemented or the class can be seen as a specialization of the interface.
In ABAP Objects, the same components can be defined in interfaces and in classes. This allows you to shift part of the public point of contact of a class into an interface, even though the class is already in use; users will not notice the difference as long as you use alias names (see appendix) for the components that are now in the interface.
A class can implement any number of interfaces and an interface can be implemented by any number of classes.
In ABAP Objects, the same components (attributes, methods, constants, types, alias names) can be defined in an interface in largely the same way as in classes. However, interfaces do not have component visibility sections.
Interfaces are implemented in classes.
The interface name is listed in the definition part of the class. Interfaces can only be implemented ‘publicly’ and are therefore always in the PUBLIC SECTION (this is only valid as of Release 4.6). If you do not do this, you risk multiple implementations, if a superclass and a subclass both implement the same interface privately.
The operations defined in the interface are implemented as methods of a class. A check is carried out to ensure that all the methods defined in the interfaces are actually present in the implementation part of the class (for global interfaces, a missing or superfluous implementation of an interface method results in a ToDo warning).
The attributes, events, constants and types defined in the interface are automatically available to the class carrying out the implementation.
Interface components are addressed in the class carrying out the implementation by prefixing the interface name, followed by a tilde (the Interface Resolution Operator):
CRM Sales Cycle Management
CRM Sales opportunity management
Sales process in Quotation and order management in CRM
No comments :
Post a Comment