Most of us know, Encapsulation, Abstraction, Inheritance, and Polymorphism are the Pillars of Object Oriented Design. There is also a fifth aspect called INTERFACE which helps to provide external access to object members.
In normal ABAP RICEF, we already have ‘I’ for INTERFACE which often is associated with data exchanges within sap or external systems. We can somewhat relate to the same INTERFACE in OOPs ABAP too.
INTERFACE is not a class. It is an entity which CANNOT have an implementation. It can only have EMPTY method declaration and components. INTERFACE components are always PUBLIC. INTERFACE is a concept by which the same method names will behave differently in different classes.
Below is an example of an INTERFACE with a method GET_KEY.
INTERFACE locker_key .
” This method GET_KEY will not have any implementation
” in INTERFACE
METHODS get_key .
ENDINTERFACE .
INTERFACE would have method(s) and those method(s) will have different implementations in different classes which call that INTERFACE. The method names in all the different classes would be same as in INTERFACE but can be designed to behave differently.
Example of a Class using INTERFACE Method GET_KEY
CLASS lcl_snoop DEFINITION .
PUBLIC SECTION .
INTERFACES locker_key .
ENDCLASS.CLASS lcl_snoop IMPLEMENTATION .
"METHOD GET_KEY is implemented here
METHOD locker_key~get_key .
WRITE:/ ‘my locker key is confidential’.
ENDMETHOD.Similarly example of another Class that uses the same INTERFACE and same method GET_KEY. But the method does something else.
CLASS lcl_history_logger DEFINITION .
PUBLIC SECTION .
INTERFACES locker_key .
ENDCLASS.CLASS lcl_ history_logger IMPLEMENTATION .
"METHOD GET_KEY is implemented differently here
METHOD locker_key~get_key .
write:/ ‘Access Date – ‘ , sy-datum, ‘Access Time = ‘, sy-uzeit.
ENDMETHOD.In the above code snippet, Class LCL_SNOOP and Class LCL_HISTORY_LOGGER are independent classes. But both use the INTERFACE LOCKER_KEY and the method GET_KEY are implemented differently although they have the same NAME in two classes.
INTERFACE IS ONE OF THE CONCEPTS IN OBJECT ORIENTED ABAP TO ACHIEVE POLYMORPHISM.
The point to be noted is, INTERFACE just contains methods WITHOUT any implementations. INTERFACE helps in re-usability and maintain standard project framework.
INTERFACE act as the connecting link. Just like the neck of the bottle in the below figure.
Now coming back to the point which we wanted to demonstrate today. Is INTERFACE the leaky bucket in OOPs ABAP? In other words, is INTERFACE the weakest link which makes the classes using it vulnerable?
Let’s explore.
We all know INTERFACE plays a vital role in large projects or developing a custom app which can be extended based on customer demand. This extension might be done by the same person or different person. To maintain the consistency in the entire project we use INTERFACES. Example BADI always gives INTERFACES which all over the world ABAPers use the same method signature to implement the INTERFACE. Inside BADI, its framework calls these INTERFACEs to show custom business implementations (eg: TAB Strip on ME21n etc).
But INTERFACE has one drawback which is like the leaky bucket in the sense that if your CLASS_1 becomes FRIEND of an INTERFACE then other classes which are NOT a friend of INTERFACE or CLASS_1 but just implements that INTERFACE, can access the PRIVATE data of CLASS_1.
Just a word of caution from SAPSPOT Team. Do take care while designing the class. Do not give a secret hole to expose your sensitive data.
Here goes the code to show how INTERFACE acts like the leaky bucket.
" An INTERFACE with a method
INTERFACE locker_key .
METHODS get_key .
ENDINTERFACE .
" Class granting INTERFACE locker_key as Friend.
CLASS lcl_mybank DEFINITION FRIENDS locker_key .
" Public to all
PUBLIC SECTION .
METHODS : get_bank_balance .
" Private to lcl_mybank
PRIVATE SECTION .
DATA : lv_bank_balance TYPE i VALUE '12000.00' .
ENDCLASS .
" Class implementing the INTERFACE for which INTERFACE is Friend
CLASS lcl_mybank IMPLEMENTATION .
" Get Bank Balance info
METHOD get_bank_balance .
WRITE : / 'My Bank Balance' , lv_bank_balance .
ENDMETHOD .
ENDCLASS .
" This class (lcl_snoop) will also implement INTERFACE (locker_key)
" but will have alleged access to lcl_myBank Private section data due to INTERFACE
CLASS lcl_snoop DEFINITION .
PUBLIC SECTION .
INTERFACES locker_key .
ENDCLASS .
CLASS lcl_snoop IMPLEMENTATION .
"Snooping lcl_myBank private variables where lcl_snoop is no where related to lcl_myBank
METHOD locker_key~get_key .
DATA : lo_mybank TYPE REF TO lcl_mybank .
lo_mybank = NEW lcl_mybank( ) .
WRITE: / 'Snoop Successfull. Account Hacked :-)' COLOR COL_NEGATIVE.
write:/ 'Amount in this bank account is - ', lo_mybank->lv_bank_balance .
ENDMETHOD .
ENDCLASS .
START-OF-SELECTION .
" A Hacker Class
DATA : lo_snoop TYPE REF TO lcl_snoop.
" New Instance
lo_snoop = NEW lcl_snoop( ) .
" Get Bank Balance of Class LCL_MYBANK (which is no where related to LO_SNOOP)
lo_snoop->locker_key~get_key( ) .Now let’s run the program and see the output.
Look, class LCL_SNOOP was able to access the Private variable (lv_bank_balance) of LCL_MYBANK. Isn’t it scary? LCL_SNOOP and LCL_MYBANK are nowhere related. So how did LCL_SNOOP access the Private Variable?
The culprit is the FRIENDSHIP of LCL_MYBANK with INTERFACE LOCKER_KEY.
For the above example, INTERFACE was indeed the MOLE in the team.
Let us remove the FRIENDS statement from LCL_MYBANK definition (commented in the above screenshot). Your program would outrightly give a syntax error. It would say, Access to Private Attribute NOT allowed.
SO, DID YOU SEE THE INFLUENCE OF INTERFACE AND IT IMPACTS TO DATA VISIBILITY AND ACCESS?
