Static Methods

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

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…

Test Fixture

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

Constructor

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.

Thumb Rules
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.