Compare OOPs method and ABAP Subroutines

Question

Hi SAP,
In my client interview i faced a question that is "Iam calling perform statement for about 100 times in my program and i have found that there is a performance issue  and what is the solution you will give to improve the performance?"
I told by using methods.
He told correct.
But i want to know how technically  methods are performing than routines. and why?
Thanks in Advance.

Answer 1

I think your Interviewer here has displayed a "pitiful" lack of understanding of this topic if he / she really actually thought this way. (The Person <b>Giving</b> the Interview not the person being asked the questions).
OOP is a different METHODOLOGY. I'll use a sales order for example.
OK in a sales order you have all sorts of data such as who the customer is, quantities and costs of the the line item(s), what the materials are, delivery instructions, delivery schedule lines etc etc. You might also need other data that comes from different SAP modules such as has the order been invoiced, has it been paid and has the amount been booked to the appropriate general ledger account.
In a "True" object orientated scenario all this data would be "encapsulated"  into a single "Sales Order Object". All you would have to do is to "Instantiate" the sales order  --I.e give it a key say sales order number and then WITHOUT ANY FURTHER PROGRAMMING  all these "Attributes" or properties of the Sales order would be retiurned to your program.
<b>As SAP is based on Relational data bases all this information needs to be read from the various distinct tables and  your object is "Constructed". -- This is what the special method "Constructor" does when you first "Create " the object / instantiate it in your application program.
Constructing this object can take a considerable amount of time and resources depending on how much data needs to be read and from how many tables.
From then onwards you've got complete access to ALL the public attributes of the SALES ORDER class</b>.
I'm leaving discussion of " Other Methods" out of this post as they are not totally relevant to the case in point.
When you call a function module you are bulding up possibly a single table or want to retrieve  / post a document etc.  This function module can be used anywhere and doesn't have any relationship to anything except  the parameters it gets from calls in your application program.
For sequential processing of large numbers of "Objects" the system has a lot more work to do INITIALLY as it has to go through all the programming to build up all the attributes FOR EVERY OBJECT. For complex objects this could involve 100's of function module calls.
Now when we get to OBJECT Orientated data bases this will not be a problem as after creation the object will be stored in its entireity so no overhead in re-building all the attributes is incurred. (The JDO for those doing JAVA does a lot of this already when "persistent objects" are used).
So your "Interviwer" was really asking the wrong questions.
OO is MUCH MUCH simpler once the objects and classes have been correctly designed and constructed. Application programming and development time can be much reduced.
However depending on what your Function module is doing in your application load on the system could bet  be much reduced compared with OO (at least until a genuine OO DBMS system is used).
In any case whether you perform a function 100 times or read all the data in one go it actually depends on what the function module actially does since you might NOT be able to retrieve everything in one go without locking the system up thereby causing longer response times for other users.
If you are running processes which are highly dependendent on the data you are accessing it could well be MUCH BETTER to retrieve this data in small doses since you won't lock the data segements for anything like the same amount of time.
OO in classical SAP does have implications with DATA INTEGRITY as well.
Say your OO aplication needs to UPDATE some of the attributes of a sales order you will need to LOCK those attributes against otherconcurrent updates being done against the "Standard SAP tables" via "Classical SAP processes and Transactions". Not an easy task here if the Class Object is complex.
However if used sensibly OO is the way forward and once OODBMS (Object Orientated data base systems) become more common place performance and data integrity issues will be solved.
Having used OO for a number of years I would certainly NEVER want to go back to classical ABAP. 
<b>Most problems with performance etc arise when people try and replicate standard sap transactions and programs with OO.  DON'T -- IT DOESN'T WORK LIKE THAT.</b>
If you really DO need to process loads of items sequentially you might find that using something like BW anyway is a better bet.
Finally not the answer most "techies" will appreciate"  but Hardware is actually very cheap these days compared to programming time, using expensive external SAP consultants, etc etc.
It Might be financially more profitable in any case just to upgrade the hardware rather than spend the time and cost of re-writing old inefficient code. (Even lower cost "Abap Factories" in India/Singapore etc cost significant amounts of money and the rising economies of those countries means in any case that's not such a cheap option anymore).
The best time for re-writing is when you start a new project so you can design the thing using OO from the START. Don't try and fit a square peg into a round hole.
Cheers
Jimbo