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 [hide]
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?
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.
No comments:
Post a Comment