Before matthew.billingham will tear out my poor head and impale it on the walls of Join Castle as warning for the future generations of fools, please try to follow the White Rabbit down the hole as I try to explain why I think so. :smile:
First of all, which is the main feature of OOP? Well, obviously is to identify and manage all the components of a report/procedure/flow as stand alone objects which can inteact each others via some public methods and can be identified by public attributes (I put it down pretty simple and somehow semplicistic, I know).
So, take as an example an easy and quick report required last week to be develop: extract all the materials open in a set of storage locations and retrieve the last material movement for that material-storage location (inbound or outbound do not count).
The user then can select one or more records and create a corrective movement for specific situation.
It's nothing too complicated and we can start to check out which are the objects we need.
The first one is obviously my APPLICATION with the report bones and structure then I can see the MATERIAL with all the logic to retrieve materials' data. As third step, we have MATERIAL DOCUMENT to get the last material document and to manage the new one. And finally our ALV to show data and manage user interaction.
Easy task, quick report but 4 objects.
I do not want to bother with a detailed explain about the report but I want to focus on the interaction bewteen MATERIAL and MATERIAL DOCUMENT (from now only MDOC).
Now that I got my objects to manage, I sink a bit deeper in them and I find out that MATERIAL is used just to retrieve data and do some check (like authorization ones on plant).
So my methods will be
- GET_DATA (public, export a table with all the materials-description-plants-s.locations-qty)
- GET_MATERIALS (private, fill main table from marc-mard)
- FILTER_AUTH (private, filter retrieved data with auth check on plant)
- SET_DESCRIPTION(private, retrieve material description)
As you can see, I kept SET_DESCRIPTION separated because if GET_MATERIALS can be easly implemented with a join, my descriptions are language dependant and I had to do a double read based first on SY-LANGU and then with english (company default).
At this point I'm forced to use FOR ALL ENTRIES based of the result of the join between MARC-MARD.
But even if I manage to extract a bunch of useless records putting in join MAKT wihout the language filter and then skim out the result from my internal table, I just got half of the informations I need.
And here the MDOC enters in play.
MDOC will have the following methods:
- GET_LAST_MDOC
- <methods for the building and calling for BAPI_GOODSMVT_CREATE>
I want to focus on GET_LAST_MDOC.
So, i got my array of materials and for each one I have to retrieve last material document and, being them 2 different objects, I cannot create any join.
So i got 2 options:
LOOP my materials, for each one retrieve the data with a bunch of selects.
Or i can use FAE, retrieve all data at start and then work with internal tables
Surely, it's a report, i can throw away the OOPs and put all in a join together but then? OOPs helps alot in organizing the code, identify the issues/objects to be threaten and I like the idea I'm building a forma mentis.
I know, FAE are deprecated and should be replaced by JOINS but… YOU CANNOT DO IT if you are going to use OOP!
How can you improve performances and void the bad guy (FAE) when you work with objects?
The power of objects is that you virtually can develop them stand alone and only later you can mix and merge them in your process/development.
And in my opinion FAE becomes quickly the only option you have to avoid the even more deprecated SELECT in LOOP
Now, Matthew, you can have my head :wink:
A little note-add:
Pointing out my failures and faults is really appreciated: I believe in constant learning so if I can improve exploiting the SCN work and experience and knowledge, why not? :grin:
