Dear community, in ABAP, we mostly work with business data. This data is often summarized in the context of a business object, also known as a “document”.
We uniquely identify such a business object with a key. Sometimes the key consists of a single component, sometimes it is composed of a combination of components.
Two examples follow. The business object “purchase order” from Procurement in Materials Management is a document number with a maximum of 10 digits. In contrast, the key of a “transfer order” from Stock Room Management (formerly Warehouse Management) consists of two separate components, the three-digit warehouse number and a document number with a maximum of 10 digits.
So far, so familiar. It is also known that in ABAP, we often work with document keys and then read the corresponding business data ourselves using SELECT based on the respective key.
Example: You need the last purchase order from supplier “Max Mustermann”. Ideally, in this example scenario, there would be a class CL_VENDOR that has a method GET_LAST_PURCHASE_ORDER. This, in turn, would most likely only return the document number, i.e., a variable with a maximum of 10 digits.
But why not return an object? After all, we’re working with ABAP Objects, which means we’re following an object-oriented design approach instead of the previous procedural one.
As a reminder: object-oriented design is all about objects interacting with each other. Classes bundle data and algorithms, which can be thought of as small, self-contained mini-worlds (islands) with clear interfaces (bridges) to the outside world.
In this sense, the GET_LAST_PURCHASE_ORDER method in our example scenario should also return an object of the CL_PURCHASE_ORDER class by default, not the key. This has the following advantages, among others:
- The consumer receives an object directly and doesn’t have to create it themselves. This saves work.
- The object offers the consumer more options because it provides data and algorithms via a well-defined interface.
- The object informs the consumer through its methods what can be done with a purchase order.
- The consumer can pass the object on.
- If the object was created based on a central standard class, this same standard class can also be centrally tested using unit tests, which significantly increases security for each consumer.
These were just five reasons. If you think about it for a while, I think there are more advantages than disadvantages. So, there’s a lot to be said for allowing objects to interact with each other in an object-oriented language.
The GET_LAST_PURCHASE_ORDER method from the example scenario should definitely return an object. If you actually need the key of the supplier’s last purchase order, a method with a clearly distinguishable name, such as GET_LAST_PURCHASE_ORDER_KEY or GET_LAST_PURCHASE_ORDER_ID, would be appropriate.
Enough object-oriented thoughts for today, have fun programming
Michael