ABAP Static vs Instance

method Which to use when?

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.

Basics
Before jumping into the difference and which should be used, check out the basics of both
Static method and Instance method.

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.
ENDCLASS.

"get_Data
"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 cant 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 havent 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
wont 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.

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

14 Comments

Wouter
# March 19th, 2013 at 5:43 am

Ok, lets think of the following scenario: custom development, custom table, create methods
and some other methods where the possibility is that according to a specific condition, they
would need to be different ( redefinition in subclass )
My current idea to best practice this (after the discussions in the previous articles ):
Objects needed:
- Static class, singleton factory which returns an instance object
- Instance superclass for the main flow
- Instance subclasses for the condition based flows
In our application, lets say a Webdynpro ABAP application, we would call the static class
factory method in the COMPONENTCONTROLLER, WDDOINIT method and we pass
along the condition based parameter.
This factory method would return an instance of the correct class (ZCL_SUPER or
ZCL_SUB_COUNTRY_A).
This would give us the flexibility, that for Country A the create would be that way, and for
country B the retrieval of a description would be another way.
We could also use the static class to initiate a BAL Log in the static constructor and add
messages to it along the way.
What do you guys think?

steve oldner

# March 19th, 2013 at 6:36 am

@Wouter that is a bit more advanced that what Im doing.

My take, static method = function-module. Instance method like a locally used and
changeable function-module.
The coolest for me is using as a functional method calls and using them instead of
variables.

Naimesh Patel
# March 19th, 2013 at 8:49 am

Hello Wouter,
Yes, I overall agree with your design. Definitely looks like a easily extendable design. A new
condition for COUNTRY_B, Inherit the super class, extend the factory/singleton method for
object creation, easy! After all OO is for easy maintenance.
For object creation, I guess what you are looking for is the Singleton, as your application
would only executed for a single condition at a time. Compare to Factory method which
gives NEW object all the time, Singleton provides the same object again and again.
Regards,
Naimesh Patel

Saurabh Tiwari
# March 19th, 2013 at 12:54 pm

Please keep posted such articlesthanks a lot

Fred Verheul
# March 20th, 2013 at 2:41 am

Hi Naimesh,
Im with you on not using static methods too much, but for me, its not (only) about methods,
its about objects. Objects encapsulate data/state with methods to do something intelligent
with the data. So for any class (= responsibility), if there is common data shared by its
methods (= how to implement the responsibility), that data should be in the attributes, and
the methods should be instance methods.
Static methods/attributes should thus be the exception, and the question which one to use
should not even be raised in general.
Just my 2 cents of course
Cheers, Fred

Naimesh Patel
# March 20th, 2013 at 9:05 am

Hello Fred,
I completely agree with you on the overall design perspective. We definitely need to think
about the responsibility and state of the objects. But as soon as you say objects, you are
going to use Instance methods. This basic guidelines would help to decide to use Objects or
not. As soon as you go for objects, there will be second stage of refactoring to achieve
polymorphism, responsibility and setting proper state
Thanks Much for your comment.

Regards,
Naimesh Patel

Wouter
# March 20th, 2013 at 1:16 pm

Hey Fred,
Agreed, but I dont emediately dare to use it on customer systems to be honest. Just
because that approach is too OO. Ive heard procedural ABAPpers already complain about
simple classes and such, also they dont like it because then Functional people or even
internal IT people cannot debug anymore ( or not as easily ) to locate issues.
If I would look at my example, a static class with create methods and methods to change
the status, and convert this to your approach, fully OO that would mean:
Instantiate an object with the key, call the create methods which prepares the records to
save to the table later on. Some update methods to set different statusses and on and
everything would be done in the attributes.
i would have to retrieve the values with getters and setters and commit to the db with a
method.
But if I would do this in mass, it would be less readable and I would always get everything
out of objects, while otherwise I can call my static create methods and append this to a
large internal table.
Any thoughts? Do you also have experiences anti-oo or better said, people not willing to
learn oo or postpone learning oo as long as possible.
Greets,
Wouter

steve oldner
# March 21st, 2013 at 5:39 am

As a customer developer, we have very little outside development. And when we do, they
must code within our standards, However, we do change and update our standards every
few years (well I instigate most of the changes usually by introducing new functionality)
The biggest complaint I have about SAPs OO code is knowing what exactly it does and is
suppose to do. Too much abstraction and little documentation (not availible in your
language!?!) make it like a nesting/nested doll, that when you get to the last one, its just
simple ABAP that would have been better in the first doll. You get the feeling they are recoding just to make it shiny and charge more money for the same thing, in a new and
improved package.
If you want to sell to a customer, make it easy for them to understand. Make it simple for
them to use. Make it easy to maintain. Show them K.I.S.S.
Flexibility We are a US state government. I dont use flexibility. Anything that is not
straightforward, or easy to understand or simple is really wasted and takes up space. When
production problems occur, I really dont need to spend my time analyzing nested code to
find out what it is suppose to do. I want to know what the data is, where it came from, and
how the result occurred.
So, when I use the OO approachs I have learned here, I run it by the most junior
ABAPPERs to see if they understand, because they will be the ones most likely to change
and maintain this code. And I take the time to review it with my QA reviewer so they
understand by using this particular OO code, I have made an improvement. Then, they do
suggest using this in other programs, and it becomes a de facto standard.
To all posters, thank you very much for posting. I learn from reading your comments.
Thanks!!

Naimesh Patel
# March 21st, 2013 at 8:57 am

Hello Wouter,
Thanks you very much for your valuable inputs.
The design you are thinking for each database record is Kind of Persistent Objects. When
using the Persistent objects, you create setters and getter methods. Each field in your table
which you want to update would become and instance attribute of your Persistent Object.
You keep on collecting the persistent object for each row in the context. At COMMIT WORK,
system would take all the active changes and update them in the DB table.
Persistent Objects are not getting much of the popularity in ABAP. Mainly the lack of Object
services to access the tables and retrieve the information from DB tables. As you have
noted, they would be performance intensive as well.
The state based design would be ideal solution for the User Entry screens like, ME21N
Purchase Order entry. That is using kind of State mechanism to handle each record. It
would generate objects for Header, for each item, for each schedule line item, etc. At save,
it would check the state of each object to decide on update.
Agree that it would be difficult for procedural IT people to understand. For developers, we
should keep our Technical Design document up-to-date with the current design. Including
UMLs would be a great idea. As long as the developers can read UML, they would be able
to understand it easily. For functional teams, they would need to keep up their skill to get
used to it.
I too get this push back from my other team members, but I would still pursue using OO
ABAP.
Regards,
Naimesh Patel

Naimesh Patel
# March 21st, 2013 at 9:01 am

Hello Steve,

I agree that when you are using OO ABAP, the newbie would have difficult time to
understand especially if they have already tasted the Procedural ABAP. But, as I
mentioned in my reply to Wouter, they should be able to understand the design if the TD is
well up-to-date.
Obviously, OO ABAP needs more time from beginning of development to testing for the
initial development. But as that software evolves, we would start reaping the benefits of that.
Thanks much for making this discussion so unique.
Regards,
Naimesh Patel

Wouter Peeters
# March 23rd, 2013 at 10:14 am

One last thought: when we talk about instance methods, we are actually always talking
about persistance objects ( using class attributes) ? The only other instance scrnario i can
think of right now is an instance class that is the application model, which does some main
things such as logging, and all other methods would act as static methods ( as in methods
who dont use class attributes you could set these as instance too to enable redefinition ).

Naimesh Patel
# March 25th, 2013 at 8:47 am

Hello Wouter,
You can use your instance methods & attributes in any context. It doesnt need to be
persistent only. For example, If you are using to update a standard document say Sales
Order using BAPI, than your class design is not Persistent. You only care about setting the
BAPI parameters from your class properly. Another example could be a report two options

 Summary and Details. Summary can be inherited from Details as summary would be
ideally total of all the amount/qty fields.
Thanks,
Naimesh Patel

Aasim
# April 6th, 2013 at 1:39 am

Hey Naimesh,
Im a regular follower of your blogs on ABAP. We, as an audience, get to learn a lot by
reading your articles. Youve, kind of, anagrammatized ABAP in a beautiful way.
I was, however, thinking that wouldnt it be great if you could write something on new
dimension topics like CRM WebUI, Webdynpro or even ALE/Idocs for that matter?
Cheerz!
Aasim

Naimesh Patel
# April 8th, 2013 at 8:49 am

Hello Aasim,
Im glad that you like the what you read on zevolving.
Regarding new dimension topics I have them lined up and they would be coming up soon.
BTW, design patterns, and all OO Stuff you find here, is a new dimension already

Regards,
Naimesh Pate