Why You Should Use ABAP Objects
If you design your code on an object basis using ABAP Objects, you have a range of advantages:
...
1. Too much global data can be a major source of error in programming. ABAP Objects enable you to hold data locally within a class or an object, and to expose only data to the outside that is actually needed there. Ideally, you provide access using Get and Set methods. These prevent internal data from being changed without authorization.
2. Writing maintainable code means that you do without copying code. Object-based programming provides the option of inheritance. If you require a class with similar semantic properties as a class that you already have, then you inherit from this class and overwrite the respective methods. A typical example is the following: You require a TRUCK class and already have the general class CAR. This class needs certain attributes that are not contained in the class CAR, such as LOADAREA, LOADVOLUME, WEIGHT. You can adopt methods such as ACCELERATE and STEER from the CAR class. The methods BRAKE and CALCULATE_BRAKING_DISTANCE would have to be re-implemented for trucks compared with the class CAR because trucks have a more effective braking system than cars.
3. Thanks to the linking of data and methods in objects, you can work with units that hold your statuses. You also have the assurance that data is processed only with the intended methods.
4. Working with independent interfaces has a major advantage when it comes to separating the interface from the implementation. In this way, you can easily change the implementation or replace an object with another one, without changing the access – as long as the new object implements the required interface.
5. A flexible coupling mechanism, based on the “publish and subscribe” model, makes for a far more flexible program flow than static procedure calls. In the case of ABAP Objects, you achieve this with events to which other methods can subscribe. In this case, they will be called whenever the corresponding event occurs.
Even if you do not wish to avail of the advantages of object-based programming, there are good reasons for using ABAP Objects all the same.
...
1. Procedural ABAP links the calling of certain program parts to events in the runtime environment, depending on the program type. This is an advantage as long as you wish to remain in the framework provided for a report, for example, and as long as you know as much about the sequence of events and what the respective consequence of an event is. This is a complex situation. It becomes even more complex through the fact that the consequence of messages of the same type are always different – depending on the event block in which the control flow is currently located.
If you do not view yourself as an expert for the events of the runtime environment, it would be better for you to use ABAP Objects. In this case, you do not have to know a great deal about implicit processes running in the background, but only about the basic concepts of ABAP Objects. Therefore, use ABAP Objects to get more explicit control on program flow in a far more simple setting.
2. To remain downward compatible, a number of statements that have now become obsolete are still allowed in procedural ABAP. In ABAP Objects, the syntax checks are much stricter: Many old statements are prohibited, many previously implicit syntax declarations must now be explicit, operations that could potentially cause errors, such as ADD-CORRESPONDING, are now no longer allowed. The use of ABAP Objects forces you into a more precise, more explicit kind of syntax that avoids errors. Using ABAP Objects you get a more stringent syntax check.
3. The new ABAP technology is programmed in ABAP Objects. Also, the user interfaces of the new ABAP technology are implemented on an object basis. This means: If you wish to use these new ABAP technologies, you must use the classes in which the respective features are implemented. Examples of this are shared objects, runtime type services, or object-oriented exceptions.
You should use function calls only where they are absolutely necessary.
· If you wish to encapsulate a classical screen, you require function modules. A class pool cannot have any screens as components.
· Classic access through RFC is only possible using function modules. You can generate server-side proxies for ABAP classes using XI and thus provide existing functions as external services in classes. However, function modules are still a better choice in comparison in order to make the functions accessible as a Web service or using RFC.
For the modularization of your program, you should use class methods - provided you do not require multiple instantiation. Use these class methods instead of subroutines. The parameter interface for subroutines is not as sophisticated as for methods. The interface parameters for subroutines are positional while those of methods are keyword parameters.