OO ABAP: When and Why?

Question

Months after my company has upgraded from 4.6c to ECC6.0, our team of programmers are still coding in the traditional 4.7c way. I'm eager to try out the new OO approach of ABAP, but much to my dismay most people here only emphasize on getting things done in the shortest time frame given.

My question would be:
1) When do people in your organization actually started coding in OO ABAP?
2) Is there any significant reason that people would want to code it in an OO way? e.g. Call Method is faster than a PERFORM statement?

Answer 1

Below are some of the advantages of OOP as you must be knowing:

• Data Encapsulation
• Instantiation
• Code Reuse
• Interfaces

Taking advantage of these, there are many important reasons for using OO ABAP "whenever possible". Even if you do not want use OO programming, using ABAP Objects is still a good idea since it provides some features that procedural programming does not.

So here's what ABAP Objects offers you over Procedural ABAP:

• Better encapsulation
• Support for multiple instantiation
• Better techniques for reusing code
• Better interfaces
• An explicit event concept

There are only two purposes for which Procedural ABAP is found essential:

• Encapsulation of classic screens in function modules.
• When you want to make functions available to other systems, but are not able to make class methods available externally using XI server proxies. In this case, you have to use function modules.

Study about them in detail here and you will see that you don't need any significant operational/demonstrative reason to convince yourself to move to OO ABAP, coz all these reasons are already very significant.

Answer 2

I don't know about ABAP, but I have seen the same happen with VB developers moving to the .Net platform.

Programmers are comfortable in their old way of programming, and the old way still works. The new way of programming takes a lot of investment, not only from the company but also from people who have to move out of their comfort zone into uncertain territory. If your company is unwilling to invest in training and time for research this problem will get bigger because people will have to invest their own time, not everyone is willing to do that.

As Taurean already showed there are convincing reasons to move to the OO way of doing things. They're mostly not about performance but about better decoupling of components in your system making it far more maintainable.

But in my experience its hard to convince people to move out of their comfort zone using reasonable arguments like that. It usually works better to show them the way. Slowly start using OO constructs in your own code, show people how clean it looks. This isn't something you'll achieve in months, it can take years to get people to think and work differently.

Answer 3

A team of experienced procedural developers is unlikely to start developing in an OO style anytime soon, unless a significant (and expensive) effort is made to train and coach them.

There are numerous reasons for that:

• It takes about a year of immersion in a real OO environment (smalltalk, not java or c++) to get any good at OO development.
• They cannot start from scratch, there is a lot of legacy code, and time pressure.
• All their legacy code is not OO. It takes a significant effort to restructure.
• The legacy code is not well structured and has lots of duplication and no unit tests. Changing it takes too much time, so they don't have time to fix things. (It's amazing what you can deduce from a project without knowing anything about it. :) ).

As a consequence, their new code will most likely be procedural but in classes and methods. They will not be impressed by the advantages of OO.

Answer 4

1) When do people in your organization actually started coding in OO ABAP?

Most developers in my organisation have learnt the classic ABAP before introduction of ABAP OO. They are mostly senior developers who restrain from learning proper OOP and OOD principles. They are still using mostly procedural ABAP features. Furthermore, we work in a legacy environment. the basics of our backend was build during the times of 4.6C. It is hard to bring proper OO Design into legacy systems.

On the other hand, the procedural features still work. Some features like transactional database updates are mostly used from the procedural part of ABAP. You might know Update Function Modules or Subroutines exclusively for database transactions (those you can call IN UPDATE TASK). They are an integral part of the ABAP basic components. One can't deny that the procedural ABAP part is still needed.

2) Is there any significant reason that people would want to code it in an OO way? e.g. Call Method is faster than a PERFORM statement?

How did you compare the runtime of CALL METHOD vs. PERFOM? Did you try the program RSHOWTIM / Or have you done some performance tests from the ABAP workbench? A single subroutine call does not differ significantly from a method invocation. However, if called in mass test method invocations have a slightly better performance (in the magnitude of microseconds).

On the whole, I recommend OOD and OOP with the same arguments as the users who posted before. But you have to keep in mind that senior developers familiar with the old ABAP world have to understand OO principles before they start writing ABAP OO. Otherwise, your organization would not profit by ABAP OO, on the contrary. There are a lot of experienced ABAP developers without OO knowledge who were pushed to write classes. What they do is actually mimicking procedural principles with classes (e.g. a class with static methods exclusively - as a substitute for function modules/subroutines).

Best of luck for your organisation for your challenge with ABAP OO! It is not about the language, it is more about getting OO principles into the mind of your staff.

Answer 5

Some good reasons to switch to ABAP OO is:

• ABAP OO is more explicit and simpler to use
• ABAP OO has a stricter syntax check which removes a lot of the ambiguity in the ABAP language
• Much of the new Netweaver functionality is only available using OO

Add this to the benefits listed by Taurean:

• Better data encapsulation
• Multiple Instansiation
• Better Garbage Collection
• Code Reuse through inheritance
• Manipulate busines objects through standard interfaces
• Event Driven programming

Starting to use ABAP OO:

• Start by calling some SAP standard OO functionality in your code: Use ALV classes, rather than the Function Modules - the classes provides much more functionality. Try calling some of the standard methods in the CL_ABAP* or CL_GUI_FRONTEND* classes
• Write a report as a Singleton using local classes
• Try designing a simple class in SE24 for something that is familiar to you (a file-handler for instance)

Resources:

1. Design Patterns in Object-Oriented ABAP by Igor Barbaric
2. Not yet using ABAP Objects? Eight Reasons why Every ABAP developer should give it a second look. by Horst Keller and Gerd Kluger

Answer 6

OO or not OO is not a question!!

Question is where OO and where NOT OO .

All advantages of OO approach (OOD and OOP) can be fully exploited as long as you are in customer name space. However every access to SAP standard functionality creates huge headaches. Transactional integrity, object consistency and synchronisation, DB commits, screens (module pools and selection screens), authority checks, batch-input. These are just some of objects that is difficult (or even impossible) to integrate in OO approach. Integration of SAP standard modules moves this to even higher level of complexity.

User-exits, Events: Most of data are provides in interface. Access to customer specific data or customisation can be placed in objects.

Reports: Most of data will be read by standard FM. Specific data processing can be placed in objects. Can be easy reused in others reports. SAP enjoy controls can be wrapped with object shell for easy using und reusing. Screens can NOT be palces in objects. :-(((

Core processing: Replacing of SAP business object maintenance or SAP processes is not encouraged by SAP. But if this is a case by patient and ready for huge effort. Lets look closer. There are a lot of technichal challanges: singleton pattern, optimisation of DB access, locking, synchronisation, etc. Separation of technical and business functionality should be adressed. Objets are not really suitable for mass procesing (high DB load) therefore mass processing should be adressed.

Answer 7

take a look at this reply: http://stackoverflow.com/questions/1470029/transition-to-oo-abap/1864441#1864441