Tuesday, 12 October 2021 07:06

Design Patterns in ABAP: Factory and singleton (and the wonderous world of OO-Abap)

Written by Jan-Willem Kaagman
Rate this item
(0 votes)
Source https://blogs.sap.com/2021/10/13/design-patterns-in-abap-factory-and-singleton-and-the-wonderous-world-of-oo-abap/
“© 2020. SAP SE or an SAP affiliate company. All rights reserved.” “Used with permission of SAP SE”

Introduction

Did you ever encounter that even after the statement DEFINITION DEFERRED you still need to move the definition of your class? Or have you ever wondered that if a singleton-class has several subclasses, why all those subclasses will be singletons, or that all classes in the tree will be one singleton? Those experiences were new to me, but I encountered them and I wanted to share my amazement.

This blog is a mixture of a how-to create a factory-class for singletons with inheritance, some surprises I found during coding and a request for advice. So please, please comment and ask questions. I would love to learn from my mistakes and wrong assumptions. I chose to not use test-driven approach to keep this blog more readable.

I was busy with some experimenting (hoping to write a blog about that later), and having re-read parts of the book “Design Patterns in ABAP Objects” by Kerem Koseoglu  I wanted to play more with these patterns. I was comparing several approaches and solutions to a problem, and wanted to have the same call to the different solutions (the polymorphism of object oriented development). As I was using operations I opted for using singletons, inheriting some standard behaviour from the superclass.

The road to a solution to test several different solutions for the same problems using inheritance and a factory class was not a straight road – not at all. It was such a bumpy ride that I thought this was worthy of its own blog. This blog first appeared at our own website.

The challenge

We want to perform an operation on something. In my case, I wanted to test several solutions for a certain operation on an object. So I need:

  • Uniformity in calling the solution.
  • Different reactions for the operation.
  • Managed instantiation.

An additional “restraint” is that this is a proof of concept. I didn’t want to clog the system with dozens of artifacts, so I created it in one program. This led to one interesting issue…

Interface and inheritance – Creating the Singleton(s)

First, I want to have uniformity in calling the solution. So I define an interface that states what operation should be used:

INTERFACE: zlif_interface. METHODS: do_something RETURNING VALUE(zrv_text) TYPE string. ENDINTERFACE.

This is the most important part of the whole solution, and now it’s done. Almost finished!

Let us think now about the other parts. It would be

Continue reading here
Read 42 times

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.