Sunday 11 August 2019

Singleton design pattern – A simple yet useful example

Introduction


The example below are based on my need to hold and transfer two fields from LIKP. It is easy to expand to hold other table structures or single fields.

The datastore could be used to replace the usage of MEMORY ID, which are not very readable / maintanable.

A (very) short introduction for those who are not familiar with the singleton design pattern. The singleton design pattern ensures that only one instance of the class is created. The class contains its own constructor, and in this method logic is placed that ensures the creation of only one instance.

And now for the fun part. I have documented the code(!), so it should be readable with just screenshots.

Class definition


The class for the data store:

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

And the O_DATA_STORE attribute:

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

Constructor


The constructor for the class is the GET_OBJECT method.

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

Methods


And two simple PUT and GET methods for the LIKP structure:

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

Use of class


The following is the test program that shows the datastore in use.

First the main program:

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

The next level in the call stack:

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

And the last level of the call stack:

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

Conclusion


At this point the LIKP-VBELN contains the number 2. This show that our data store object are kept in memory the whole way through the call stack.

Please note that if you leave the call stack (i.e. start another report), then you will loose the reference to the object.

With this datastore class you can now avoid using MEMORY ID to store and move variables trough the call stack.

Further enhancement

After the initial build of the class I have enhanced it further, and changed the GET-methods with a return parameter to evaluate if the field has been stored.

I also added a RESET-method. This method marks the field as unstored.

This has the advantage of being able to check if the field have been initiated. And also to reset the field after it have been retrieved/used.


SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

METHOD put_berot.
  v_berot = i_berot.
  v_berot_initiated = abap_true.
ENDMETHOD.

METHOD reset_berot.
  v_berot = ''.
  v_berot_initiated = abap_false.
ENDMETHOD.

SAP ABAP Certifications, SAP ABAP Tutorials and Materials, SAP ABAP Learning, SAP ABAP Online Exam

METHOD get_berot.
  e_berot = v_berot.
  r_berot_initiated = v_berot_initiated.
ENDMETHOD.

No comments:

Post a Comment