Object Oriented Abap Tutorial Pdf
DATA:TSFLIGHT TYPE TABLE OF SFLIGHT,FSSFLIGHT TYPE SFLIGHT.DATA:RCONTAINER TYPE REF TO CLGUICUSTOMCONTAINER,RGRID TYPE REF TO CLGUIALVGRID.SELECT. FROM SFLIGHT INTO TABLE TSFLIGHT.CALL SCREEN 100.&-.& Module STATUS0100 OUTPUT&-text-MODULE STATUS0100 OUTPUT.SET PF-STATUS 'SCREEN1'.SET TITLEBAR 'TITLE1'.ENDMODULE.
Before you can begin to grasp OO-related concepts such as inheritance or polymorphism, you must first understand the fundamental concepts of classes and objects. This article will introduce you to these ideas. Why do we need classes?With all of the robust data object types available in the ABAP programming language, you might wonder why we even need classes in the first place. After all, isn’t a class just a fancy way of defining a structure or function group? This limiting view has caused many developers to think twice about bothering with OO development. As you will see, there are certain similarities between classes and structured data types, function groups, etc. However, the primary difference with classes centers around the quality of abstraction. Classes group data and related behavior(s) together in a convenient package that is intuitive and easy to use. This intuitiveness comes from the fact that classes are modeled based on real-world phenomena. Thus, you can define solutions to a problem in terms of that problem’s domain – more on this in a moment. Classes and Objects: DefinedOver the years, the term class has been adopted by most OO languages to describe the concept of an abstract type.
Here, the use of the word “class” suggests that developers are surveying the problem domain and “classifying” objects within that environment. For example, when developing a financial system, it stands to reason that you might identify classes to represent accounts, customers, vendors, etc. Generally speaking, any noun in a functional specification could suggest a particular object.
Of course, it is important to remember that a noun describes a person, place, thing, or idea. In the financial example above, it is easy to identify things like accounts, etc. However, an abstract concept like a dunning process is an equally good candidate for a class.You can think of a class as a type of blueprint for modeling some concept that you are simulating in a problem domain. Inside this blueprint, you specify two things: attributes and behaviors. An attribute describes certain characteristics of the concept modeled by the class. For instance, if you were creating a “Car” class, that class might have attributes such as “make”, “model”, “color”, etc.
Technically, attributes are implemented using various data objects (e.g. Strings, integers, structures, other objects, etc.). The behavior of the class is defined using methods. The “Car” class described earlier might define methods such as “drive( )”, “turn( )”, and “stop( )” to pattern actions that can be performed on a car. The figure below shows an example of the class “Car” with some basic attributes and methods.The “Car” class described above only defines a blueprint for building a car – and not the car itself. Taking the blueprint metaphor a step further, consider the difference between a set of blueprints for a house and a house that is built in reference to those blueprints. The blueprints for a house describe basic dimensions, layouts, etc.
In other words, they provide instructions for building a house. A homebuilder takes these specifications and builds an instance of this house. An instance of a house has a unique physical address and can be customized to suit a persons preferences. In OO-parlance, an instance of a class is called an object. The relationship between a class and object instances of that class is shown in the figure below.Defining Classes in ABAP ObjectsNow that you know what a class is, let’s look at how to define one using ABAP syntax. In ABAP, a class is developed in two parts: a definition section and an implementation section. The definition section for the “Car” class described above looks like this:CLASS lclcar DEFINITION.PUBLIC SECTION.METHODS:drive IMPORTING imdrivingspeed TYPE i,turn IMPORTING imdirection TYPE c,stop.PRIVATE SECTION.DATA:make TYPE string,model TYPE string,color TYPE string,drivingspeed TYPE i.ENDCLASS.In my next blog, we’ll go into more details about the PUBLIC SECTION and PRIVATE SECTION specifiers you see in the class definition. For now, it is enough to simply note that we have defined a class called lclcar that contains methods and attributes.
As you can see, attributes are defined using the same data types you would use to define a global or local variable in a non-OO context. Similarly, methods can be defined to have various parameter types just like form routines or function modules.Presently, our lclcar class does not have any implementation for the methods drive( ), turn( ), and stop( ). These methods must be implemented in the implementation section of a class definition.
The syntax for the implementation section is shown below:CLASS lclcar IMPLEMENTATION.METHOD drive.drivingspeed = imdrivingspeed.WRITE: / ‘Current speed is:’, drivingspeed.ENDMETHOD.METHOD turn.IF imdirection EQ ‘L’.WRITE: / ‘Turning left’.ELSE.WRITE: / ‘Turning right’.ENDIF.ENDMETHOD.METHOD stop.drivingspeed = 0.WRITE: / ‘Stopped.’.ENDMETHOD.ENDCLASS.Now that our class is fully defined, we will do something useful with it in the next section. Instantiating and Using ObjectsOnce a class is defined, you can create instances of that class in your programs. ABAP does a really nice job of abstracting the instantiation process so creating an object is a breeze.
However, the abstraction process implies that you do not have direct access to an object at runtime. Rather, you work with objects via an object reference variable that points to the object. Object reference variables are defined like this:DATA: lrcar TYPE REF TO lclcar.The previous syntax defines an object reference variable called “lrcar” that references objects of type “lclcar”. Once the reference variable is defined, you can create an object using the following syntax:CREATE OBJECT lrcar.The CREATE OBJECT statement asks the ABAP runtime environment to build an object of type lclcar and store a reference to that dynamically generated object inside the reference variable lrcar. You can think of this reference variable kind of like a remote control that can be used to interface with the object it points to. To “press buttons” on this remote control (i.e. Access data, call methods, etc.), you use the object component selector (or “-”) operator.
The example code below shows how to invoke methods on a generated car object:lrcar-drive( 55 ).lrcar-turn( ‘R’ ).lrcar-stop( ).As you can see, onenice thing about objects is that they are really easy to use. Therefore, you don’t have to be an OO guru to start using some really handy classes in your programs. Indeed, if you search for classes matching the pattern “CLABAP.” in transaction SE24, you will find many useful classes that SAP has provided out of the box with the AS ABAP.
SummaryHopefully by now you have learned how to create simple classes and use them in your programs. In my next blog, I will show you how to use access specifiers to implement encapsulation and data hiding in your classes. Good blog on OO-ABAP, James.For those who were hesitating to dive into ABAP-Objects will find this lucidly written blog very interesting.You have righlty mentioned the declaration of data still resembles the procedural way of coding.
Sap Abap Object Oriented Programming
In future blogs, you may please take up the code written in procedural way and how that can be converted to ABAP- objects.This will help developers to think in terms of Object way of coding rather than go for procedural way.Keep up the good work and hoping to see many more blogs on the subject.Regards-KJ. Hi James,I have the same limited point of view as you explained and even after your blog couldn’t figure out why one can not define structures with same atributes as Classes and the Methods as function modules (just to keep the private public accessibility apart for time being).I just can’t appreciate the difference OO will make from a design efficiency perspective when compared to our original ABAP.Not sure if i shall ask questions here.but will be great if you could explain if the community rules permitThanks. Hi Abhishek,Technically, you are correct. It is certainly possible to maintain data and behavior separately as structures and function modules. However, my quesiton for you would be – why would you want to? It takes a considerable amount of discipline to make sure that the integrity of the data is not compromised.
Accessibility rules allow you to take control of this situation by directing any and all access to various data attributes through methods. Within these methods, you can perform authorization checks, validations, etc. To ensure that data is never updated erroneously.In addition to improving the integrity of data, encapsulation also helps you achieve more autonomy with your objects. The basic idea of the OO paradigm is to model a system based on real-world phenomena.
Thus, if a class represents a particular entity, it should assume all of the attributes/behaviors of that entity. In short, it should be able to stand (and think) on its own. Building autonomous objects reduces dependencies, allowing you to simplify a system.Many ABAP programs are designed with a huge START-OF-SELECTION event module that has pages and pages of subroutine calls. To me, this is analogous to building a car with a monolithic engine design. Because the subroutines are dependent on external data, you cannot easily plug them into other programs without combing through them to see what data they need to do their job. Encapsulated objects are like parts.
A well-designed OO program should look like a Honda underneath the hood – clean, concise, elegant.Finally, it is important to look at the whole picture when considering OO development. Encapsulation is just one of the pillars of OO design; inheritance and polymorphism are equally important. However, you’ll find that you can’t achieve one without the other. Hopefully that compels you enough to give it another thought. Thanks for your feedback.Best Regards,James. Hi Ashutosh,From a technical perspective, yes. The primary difference in the OO context is that SAP deprecated certain language elements that should no longer be used.
Here, it’s not so much a case that these elements are impossible to use in classes. Rather, since classes were new, it gave SAP an opportunity to enforce certain syntax rules without impacting the mounds of legacy code that were still using these elements.Realistically speaking, it’s hard to completely dismiss procedural programming in ABAP as there are still useful technologies based on it (i.e.
Object Oriented Abap Tutorial Pdf Download
RFCs, business objects used in workflow, etc.). However, for new developments, I think the OO style makes a lot of sense. Indeed, you’ll see that more and more of the standard code delivered by SAP is object-oriented.
This is especially the case in new dimension systems like CRM, SCM, etc.Hope this helps.Thanks,James.