Adapter design pattern, another widely used design pattern in the real world as well as the Object Oriented Programming language. Standard SAP developments build in OO ABAP also uses Adapter DP a lot.
What is Adapter
Adapter converts the objects which are incompatible due to the difference in the “Interface”. By implementing Adapter, we can allow classes to work together, which can’t work without implementing the Adapter.
Sometimes, we have a client who expects the object with certain interface only. We do have another object which can satisfy the requirement but both object’s interfaces are different. So, we can’t directly call the existing object with using the same interface. So, we need to create a kind of “wrapper” which can translate the objects interface to the interface which is accepted by client or other object.
Sounds familiar? yes, we use this type of wrapper in lot of situation – both in real world and in Programming. In real world, we use like Mini SD card reader with USB, so we can read the data from it. In ABAP, std SAP uses this in most of the BAPI FMs.
UML for Adapter
Here is the UML for our demo:
We have a simple output class implementing the LIF_OUTPUT. Client is using the interface LIF_OUTPUT to interact with output object. Lets see how Adapter is achieved:
- LIF_OUTPUT – Client accpets to only work with the objects with this interface only. So, all our objects which should interact with client must have this interface. This component is called as “Target”.
- TREE_OUTPUT – This is the object which doesn’t have the same Interface. But this object satisfies all our requirement to generate the TREE output. This component is referred as “Adaptee”.
- NEW_COMPLEX_OP – This is a new object who act as Wrapper on TREE_OUTPUT with the interface of LIF_OUTPUT. So, client can seamlessly generate the complex output (TREE) with using the same interface. This is called as “Adapter”.
SALV model uses Adapter to map the attributes from SALV compatible interface to Classical ALV or ALV Grid attributes.
Code Lines
Lets checkout the code lines on how to achieve Adapter in OO ABAP.
Adapter Design Patter in OO ABAP
REPORT ZNP_DP_ADAPTER. * INTERFACE lif_output. METHODS: generate_output. ENDINTERFACE. "lif_output * CLASS simple_op DEFINITION. PUBLIC SECTION. INTERFACES: lif_output. ENDCLASS. "simple_op DEFINITION * CLASS simple_op IMPLEMENTATION. METHOD lif_output~generate_output. WRITE: / 'Simple Output - just using WRITE'. ENDMETHOD. "lif_output~generate_output ENDCLASS. "simple_op IMPLEMENTATION * CLASS tree_output DEFINITION. PUBLIC SECTION. METHODS: generate_tree. ENDCLASS. "tree_output DEFINITION * CLASS tree_output IMPLEMENTATION. METHOD generate_tree. WRITE: / 'Creating Tree ... using CL_GUI_ALV_TREE'. ENDMETHOD. "generate_tree ENDCLASS. "tree_output IMPLEMENTATION * CLASS new_complex_op DEFINITION. PUBLIC SECTION. INTERFACES: lif_output. ENDCLASS. "new_complex_op DEFINITION * CLASS new_complex_op IMPLEMENTATION. METHOD lif_output~generate_output. DATA: o_tree_op TYPE REF TO tree_output. CREATE OBJECT o_tree_op. o_tree_op->generate_tree( ). ENDMETHOD. "lif_output~generate_output ENDCLASS. "new_complex_op IMPLEMENTATION * START-OF-SELECTION. DATA: o_op TYPE REF TO lif_output. CREATE OBJECT o_op TYPE simple_op. o_op->generate_output( ). * using the same "simple" Interface to perform the "complex", * Since Client only wants to use Simple interface .. CREATE OBJECT o_op TYPE new_complex_op. o_op->generate_output( ).
Design Time Considerations
We should consider this while implementing the Adapter.
- Create a class implmenting the same interface which is requried by Client
- Instantiate the Object whose Interface is incompitible
- Call the respective methods to perform an action within the implemented methods of interface.
Let me know, if you have implemented this design Pattern and realized its benefits.
No comments:
Post a Comment