Combining the power of both design patterns: Singleton and Factory Method. Singleton produces the same object again where as Factory instantiates new object every time asked. Lets see how they both come together..
Page Contents
Background
Few days back, I read the post on SDN – Factory Design Pattern. The post reminded me that I use the similar infrastructure for object creation. I would not prefer to name as the Factory as Factory is strictly to generate the new object when it is called. So, I thought of giving this pattern a new name – Singleton Factory Design Pattern.
What is Singleton?
The purpose of the Singleton Design pattern is to return the same object over and over to the caller. Singleton would be useful when you need to have an access to same object in the different part of an application. E.g. when you are working with the user-exits, it would be better to use the Singleton object as you can set certain attributes which can be used later on.
What is Factory?
The purpose of the Factory method is to provide a new instance of the object whenever the Factory method is being called. When you are dealing with lot of different interrelated classes, it is better to use the Factory to streamline the object creational.
What is Singleton-Factory?
You have guessed it correct – combination of both: Singleton & Factory.
Using the Factory method to always get a new object. This Object would be saved in the internal table with the key. If the Key is different than available keys in the Singleton Object collection, we would instantiate a new object by calling the Factory Method.
Typical implementation of Singleton Factory should be like this:
Since, we have Internal tables – which are very powerful – in SAP, it would be better to save the instances if we think it could be used later in the application. But, you need to be also careful while saving the instances as they would be only killed when Session gets over.
When do you need to use Singleton Factory?
When you have to use the same object again, but this object should be different based on the different keys. So, if you only call the Factory, you get a new object all the time which would kill the idea of getting the same object for the key. If you only use the Singleton, you get the same object over-and-over. This would also defeat the purpose of using the different object based on the key. In this type of scenarios, when you need to have different objects based on different situation but you may need the old object again later in the game, you should use the Singleton Factory Method.
Real-time Scenario
Requirement is to write a Log in the file. This Logger would be called from the inbound interface processing via job. This job would process different message types at the same time. There should be different Log files based on the message type.
So, I created a static attribute internal table with key (message Type) and File Object (ZCL_LOG_FILE). This table would store all the instances of the object along with the message type. The method signature contains the importing parameter as Message Type key and returning parameter of the object. Read the table with key, if object found it would be used. If not found, new object would be created using the Factory and saved in the table.
Discussion
I have to ask you few questions:
- Do you think this is appropriate name?
- Did you use similar type of Design Pattern?
Saw the singleton object on a IT Toolbox thread on how to pass an itab from one program to another. Now reading your blog on using the singleton for writing LOG entries. Sorry, I am missing something. My understanding is not good enough. What would this type of coding replace? A function module call to update ZCL_LOG_FILE? SQL to update ZCL_LOG_FILE?
Hello Steve,
Singleton is design pattern, it can be used for any purpose. The example, I am trying to saw is within the Inbound IDOC processing. You can schedule the job on RBDAPP01 to process the IDOCs. This IDOCs would be then processed by the Inbound Process Code. Based on the Packet size on the RBDAPP01, system would call the inbound process code multiple times.
Now, you want to collect the error messages for each of the IDOC in the same file. So, you create the Singleton object for the log file ZCL_LOG_FILE. The same job could process different message types, thus it is required to collect them in different Files. So, you create the ZCL_LOGGER which would hold all of your singleton objects. But this singleton objects are based on the Message Type.
Please let me know, if I have increased your confusion.
Regards,
Naimesh Patel
Hello,
small correction to method get_object:
if method doesn’t find anything in i_objs table, it creates an object, but doesn’t return it. I think it should.
Best Regards,
Grzesiek
Grzesiek, Thanks for pointing that out. I replicated the actual production code for this example and I missed that. I’ll correct it.
Regards,
Naimesh Patel
Hi Naimesh,
very good tip. I’m a ABAP Development since 2004 but never had the chance to use Design Patters on my developtments, since I never have found many examples to implement it.
Good to know that scenarios is changing and I already add your blog to my Favorites.
Best Regards,
Ademir
PS: Sorry for my poor english.
Hello Ademir,
Glad that you like the posts on Design Pattern. If you use ABAP Objects, you should use Design Patterns to make your software robust and easily maintainable.
My whole purpose to write on Design pattern with some real time examples, is to bring the Design Patterns into the regular development.
Btw, you English is good, no need to feel ashamed of that.
Regards,
Naimesh Patel
Is there a difference between the Singleton-Factory and a Pool Pattern (http://en.wikipedia.org/wiki/Object_pool_pattern)?
Hello Tom,
Thanks for pointing me to Object Pool design Pattern. Frankly, I didn’t heard that before so, didn’t pay much attention on searching if there is an existing name for this type of design pattern.
I guess, Singleton Factory and Object Pool, both would have same characteristic and functionality – Thus, no difference.
Thanks again,
Naimesh Patel
Hi Patel, I am new to usage of design patterns, i am thinking of the use case, where initializing the communicator/outlook in the system can be said as a use of singleton pattern? As how many times you click on them only f refer to the same object.
Hello Rakesh,
Yes, Outlook and Communicator both can be considered as Singleton object. They would leave until you close the application.
In ABAP world, you can use the Singleton design pattern say in Sales Order User Exits. I am not sure if you are familiar with the SO user exits. There is MOVE_VBAK, CHECK_VBAK, MOVE_VBAP and so on. You can create a singleton object and use for the life of the Sales Order thus you can minimizes the redundant data selection and further processing.
Regards,
Naimesh Patel
It took me a while to adapt the code to 4.6c, but I think I got it now. Though being an ABAP beginner, I’m now the first in my company (as far as I know) who used a design pattern in ABAP Objects 🙂
Thank you very much for this tutorial!
i didnt understand these log files example could please explain with any other example…