We all debate over when to use Static methods or Instance methods. Most of the times we go for simplest approach, but that may not be the correct one. Lets try to explore and see what should be possibly the best approach when deciding Static or Instance.
Before jumping into the difference and which should be used, check out the basics of both – Static method and Instance method.
Static methods are methods which can be called irrespective to the class instance. You can access only static attributes and static events within the Static method.
This is how you declare and call static method:
* static method declaration CLASS lcl_data DEFINITION. PUBLIC SECTION. CLASS-METHODS: get_data IMPORTING iv_date TYPE d. ENDCLASS. "lcl_data DEFINITION * * static method call - calling using class name lcl_data=>get_data( '20130313' ). * CLASS lcl_data IMPLEMENTATION. METHOD get_data. * do something ENDMETHOD. "get_Data ENDCLASS. "lcl_data IMPLEMENTATION
Instance methods are methods which can be ONLY called using the object reference. Instance methods can access instance attributes and instance events.
This is how you declared and call instance method:
*Instance method declaration CLASS lcl_data DEFINITION. PUBLIC SECTION. METHODS: get_data IMPORTING iv_date TYPE d. ENDCLASS. "lcl_data DEFINITION * * Instance method call - calling using the object reference DATA: lo_data TYPE REF TO lcl_data. CREATE OBJECT lo_data. lo_data->get_data( '20130313' ). * CLASS lcl_data IMPLEMENTATION. METHOD get_data. " get data ENDMETHOD. "get_data ENDCLASS. "lcl_data IMPLEMENTATION
Why not to use Static methods
As you can see from the sample code, It may sound good and lucrative to create a static method as it does not involve long steps when calling the methods – declaring reference variable, instantiating the object and calling method. Static method can be directly called without doing these steps. But the design using static will not be as good as it sounds. Let me show you why:
Static methods cannot be Redefined
One of the most important aspect of the Object Oriented programming is the Polymorphism – replacing the default implementation with the more specific implementation whenever its required. In OO ABAP the polymorphism would be achieved using Method Redefinition. As we have discussed in earlier article Override Static method, we can’t redefine Static methods. The primary reason behind this is static methods are operable on their own. With static methods, you call them by explicitly specifying the type on which they are defined. Which means, you directly call the implementation, which is not bound to any specific implementation of the instance object.
Lets see this by the a simple scenario – If you have static method which does the Sales Order Creation using the BAPI. When you designed, this method was only used for one business scenario. Now, you want to use this for different business scenario. In this new scenario, you need to set some additional fields on item, like Higher Level item, determine a new item category etc. What you would think as a simple solution would be to add a code block in the method to do this logic for XYZ Sales Area, ZABC order type. What you have done here is opened a box where you would keep on adding more and more conditions. Thus violating the Single Responsibility Principle.
If you had an Instance method, you could have easily inherited another class, redefined the method and replaced the existing implementation. In this new implementation, you set the additional fields and call Super Method to do the rest.
Problem in ABAP unit testing
I haven’t covered ABAP Unit yet. They are coming soon…
In ABAP unit, you can set the test data in special methods called test fixtures. After this method, your test method would be called where you have access to test data. Since each ABAP Unit test should be operable and testable on its own, Static methods makes it very difficult to test with. Static methods would use static attributes and since they are using that, you have to have additional logic to get rid of them all the time in your test fixture methods.
If you are working with the instance if the object, it can be easily cleared. When you instantiate a new object, the old object would be de-referenced without any additional logic
Design using the static methods would end up using the CLASS_CONSTRUCTOR, as opposed to the method CONSTRUCTOR for Instance methods. As I noted earlier, CLASS_CONSTRUCTOR and CONSTRUCTOR: Who comes before whom?, it would be difficult to predict when CLASS_CONSTRUCTOR would be called. CLASS_CONSTRUCTOR can be called when the class is first accessed even though it was accessed to get Constant value. This makes it inoperable and un-testable on its own.
Reuse the Utility in same Session
Static attributes would be bound to memory till the session is over. This means that if the values are set once, they wont be cleared until the session is finished. If static attributes it won’t be possible to leverage the same logic in the same session. E.g. A simple utility class to generating Application Log.
The design is like:
- Collect log in an attribute of the static class
- Call static method to generate Application log after the collect.
The design seems fully appropriate for the utility class which should be static. But the problem with this is, it restrict you from using the same logic again in the same session without losing the existing information. Lets say, you are collecting a errors using this application log. Now, in the same program, you wont to generate another application log to track the activities performed. Since you have collecting all the errors in the static attributes, unless you copy it into another placeholder and call the Utility class for generating the tracking log, you would lose the error log data when you try to use the same Utility class.
On the other hand, you had a design using instance method and attributes, you would be able to simply create another instance and start using it for tracking log.
So based on all these facts, we can conclude to these thumb rules:
- If you are planning to create any static attribute which would be used by static method, Consider creating instance methods. It would allow you to work with multiple instances. It also allows you to control on when you can free up the bound memory.
- If you think that there would be a chance to add a conditional logic in future, Go for instance. This makes design more flexible by allowing you to leverage polymorphism by Redefinition
- Static should only used for object creation design patterns like Singleton, Factory Method, Abstract Factory, Singleton Factory to facilitate the object creation.
- Static should be for pure utility classes not for helper classes. The best examples would be methods within the class CL_GUI_FRONTEND_SERVICES.
Let me know if you want to add any other perspective of using vs not using the Static method.
On a side note
Implemented quite a few changes on site Homepage and other pages including Navigation, Menu, Related Post etc. The site is also now mobile (iPhone, Android, Nokia, and others) as well as tablet (iPad, Galaxy and others) friendly. Check it out and let us know your feedback.