OOPS ABAP 1 Information systems used to be defined primarily by their functions: data and functions were stored separately

and linked using input-output relationships. Object orientation focuses on objects that represent either abstract or concrete things in the real world. They are first viewed in terms of their characteristics, which are mapped using the object s internal structure and attributes !data". The behavior of an object is described through methods and events !functionality". Objects form capsules containing the data itself and the behavior of that data. Objects should enable you to draft a software solution that is a one-to-one mapping of the real-life problem area.

#onsistency throughout the software development process The $language% used in the various phases of software development !analysis, specification, design and implementation" is uniform. The ideal would be for changes made during the implementation phase to flow back into the design automatically. &ncapsulation &ncapsulation means that the implementation of an object is hidden from other components in the system, so that they cannot make assumptions about the internal status of the object and therefore dependencies on specific implementations do not arise. 'olymorphism 'olymorphism !ability to have multiple forms" in the conte(t of object technology signifies that objects in different classes have different reactions to the same message. Inheritance Inheritance defines the implementation relationship between classes, in which one class !the subclass" shares the structure and the behavior defined in one or more other classes !superclasses". )ote: *+*' Objects only allows single inheritance. +efore *+*', ,*' used to use a macro assembler. *+*' was created with the intention of improving reporting. *+*' is a relatively independent in-house programming language, although it was influenced by other programming languages, for e(ample, #O+O- and '*,#*-. *+*' Objects is a true e(tension of *+*'. *+*' Objects unites the most promising

aspects of other object-oriented programming languages, such as .ava, #// and ,malltalk. 0ou need to assign types more fre1uently in *+*' Objects than in *+*'. 2or e(ample, in *+*' Objects, when you are defining interface parameters for methods, you must assign types to the parameters. The correct pass by value is then checked by the system when the method is called. +y comparison, in *+*' you do not need to assign types to the parameters of function modules, for e(ample. *+*' Objects is not a new language, but has been developed as an e(tension of *+*'. It integrates seamlessly into *+*' synta( and the *+*' programming model. *ll enhancements are strictly upward compatible. In object-oriented programming, the analysis and design phase is even more important than it is for procedural programming. The reason for this is that in object-oriented programming, decisions taken during the analysis and design phase have even more pronounced effects on implementation than they do in procedural programming. 34- !3nified 4odeling -anguage" is a standardi5ed modeling language. It is used for the specification, construction, visuali5ation and documentation of models for software systems and enables uniform communication between various users. 34- does not describe the steps in the object-oriented development process. 34- is an industry standard and has been standardi5ed by the O46 !Object 4anagement 6roup" since ,eptember 7889 as 34- :ersion 7.7. The members of the O46 are continuously developing it further. ,*' uses 34- as the company-wide standard for object-oriented modeling. 34- describes a number of different diagram types in order to represent different views of a system. 3se-case diagrams show the relationships between agents and actions !use cases", that is, they represent e(ternal system behavior from the user s point of view. #lass diagrams show the static view of a model. Interaction diagrams demonstrate the relationships and method calls between objects. ,e1uence diagrams emphasi5e the timing se1uence of the method calls, while collaboration diagrams focus more on the object relationships and their topology. ,tatus diagrams show a se1uence of statuses that an object can adopt during its lifetime,

and the stimuli that cause this status to change. *ctivity diagrams are a special type of status diagrams. They mostly or e(clusively contain activities. #omponent diagrams show the organi5ation and dependencies of components. ;istribution diagrams represent the dependencies of software and hardware. OOPS ABAP 2 34- notation: The slide depicts two ways of representing classes. In the first, the class is represented by its name, attributes and methods, in the second, the name only is used. 34- also offers you the option of omitting the either the attribute or the method part. *+*' Objects events are not represented in class diagrams. * class diagram describes the elements contained in the model and their various static relationships. There are two basic forms of static relationships: *ssociations !for e(ample, a flight customer books a flight" 6enerali5ation<speciali5ation !for e(ample a cargo plane and a passenger plane are planes" #lasses can also be shown with their attributes and methods in the class diagrams. *n association describes a semantic relationship between classes. The specific relationship between objects in these classes is known as an object link. Object links are therefore the instances of an association. *n association is usually a relationship between different classes. =owever, an association can also be recursive> in this case, the class would have a relationship with itself. In most cases, recursive associations are used to links two different objects in one class. The points below assume that the associations are binary. &ach association has two roles, one for each direction of the association !flight booking?customer, customer -? flight booking". @oles can have names !for e(ample, the association flight-?flight booking could be called reservations". &ach role has a cardinality that shows how many instances participate in this relationship. The multiplicity is the number of participating objects in one class that have a relationship to an object in the other class. 34- notation:

*n association is represented by a line between the class symbols. The cardinality of the relationship can be shown at each end of the line. *ssociations can be given a name for ease of identification !a verb or a short te(t". This name is written in italics above the line and may have a arrow to show the direction. +oth are optional. *ggregation is a special kind of association. *ggregation describes one object that contains another or consists of other objects !whole-part". *n airplane consists of wings. The relationship can be described by the words $consists of% or $is a part of%. 34- notation for aggregation: *n aggregation, like an association, is represented by a line between two classes, which then additionally has a small rhombus at one end. The rhombus is always at the aggregate end, that is, the whole object end. Otherwise the notation conventions are the same as for associations. #omposition is a special kind of aggregation. #omposition describes the fact that the object contained cannot e(ist without the aggregate !for e(ample, a flight booking cannot e(ist without the relevant flight". ;ifferences between composition and aggregation: The cardinality on the aggregate side can only be one. &ach part is only part of one composite object, otherwise the e(istence dependency would be contradictory. The lifetime of the individual parts is linked to the lifetime of the aggregate: parts are created either with or immediately after the aggregate, and they are destroyed either with or immediately before the aggregate. 34- notation for composition: -ike aggregation, composition is shown as a line between two classes and marked with a small rhombus on the aggregate side. =owever, in contrast to aggregation, the rhombus is filled in. 34- notation: 6enerali5ation and speciali5ation are denoted by triangular arrows that point from the subordinate class to the superclass. ,everal arrows can be summari5ed into a tree. ,e1uence diagrams, unlike class diagrams, show the dynamics between objects. They are used to represent a particular process or a particular situation. ,e1uence diagrams focus on the time se1uence of the information e(change: #reating and deleting objects. 4essage e(change between objects.

,e1uence diagrams have no notation for representing static methods. 34- notation: Objects are represented by s1uares. 0ou can write the object name in these s1uares in various ways: Object name Object name:class name class name The object life line is represented by vertical dotted lines. The control focus is shown as a vertical rectangle on the object life line. The control focus shows the objectAs $active% period: *n object is active when actions are e(ecuted *n object is indirectly active if it is waiting for a subordinate procedure to end. 4essages are shown as hori5ontal arrows between the object lines. The message is written over the arrow as 4ethod !parameter". There are various options for representing the reply> in this e(ample, the arrow is shown as a returning arrow. 0ou can also include a description of the process and add comments to the object life line as re1uired. OOPS ABAP 3 The object in the above model has two layers: an outer shell and an inner core. 3sers can only see the outer shell, while the inner core remains hidden !the internal status of an object can only be seen within the object itself". 'ublic components !outer shell": the outer shell contains the components of the object that are visible to users, such as attributes !data", methods !functions" and events. *ll users have direct access to these components. The public components of an object form its e(ternal point of contact. 'rivate components !inner core": the components of the inner core !attributes, methods and events" are only visible within the object itself. The attributes of an object are generally private. These private attributes of an object can only be accessed using the methods of that object itself. Bhy are the private components of an object $hidden%C This principle is called $information hiding% or $encapsulation% and is used to protect the user.

-et us assume that an object changes its private components, while its e(ternal point of contact remains unchanged. *ny user who simply needs to access the object s e(ternal point of contact can carry on working with the object as usual. The user does not notice the change. =owever, if an object changes its public components, then any user who accesses these public components must take these changes into account. &very object has an identity, a status !1uantity of attributes" and behavior !1uantity of methods and events". The structure and behavior of similar objects are defined in a class which they share. Identity is a characteristic that differentiates each object from all other objects. Identity is often confused with having the same attribute values or with a uni1ue name. Two different objects can have identical attribute values and still not be identical. &(ample: Two coffee cups are the same height and diameter, have the same handle and are both white. *lthough they look e(actly the same, they are still two separate cups. In the real world, there are objects, such as various airplanes and plane tickets. ,ome of these objects are very similar, that is, they can be described using the same attributes or characteristics and provide the same functions. ,imilar objects are grouped together in classes. &ach class is described once, and each object is then created in accordance with this blueprint. * class is therefore a description of a 1uantity of objects characteri5ed by the same structure and the same behavior. *n object is a concrete e(ample of a class, the airplane class is a description of the objects -= 4unich, -= )ew 0ork etc.. Objects that belong to the same class have the same attributes and can be accessed using the same methods. There is only one of each class within a software system, but each class can contain several objects. OOPS ABAP 4 In this conte(t, abstractions are a simplified representations of comple( relationships in the real world. *n actually e(isting object is abstracted to the significant dimensions that are to be mapped. Insignificant details are left out in order to aid understanding of the overall system. This e(ample concerns airplanes. ,oftware for airlines and software for an airport s hangar management contain different abstractions !classes" for these objects.

* class can contain very different objects depending on the abstraction. * class is a description of a number of objects that have the same structure and the same behavior. * class is therefore like a blueprint, in accordance with which all objects in that class are created. The components of the class are defined in the definition part. The components are attributes, methods, events, constants, types and implemented interfaces. Only methods are implemented in the implementation part. The #-*,, statement cannot be nested, that is, you cannot define a class within a class. *ttributes describe the data that can be stored in the objects in a class. #lass attributes can be of any type: ;ata types: scalar !for e(ample, data element", structured, in tables *+*' elementary types !#, I, ..." Object references Interface references *ttributes of the airplane class are, for e(ample: )ame ,eats Beight -ength Bings Tank In classes, you can only use the T0'& reference to refer to data types in the *+*' ;ictionary. 0ou can only use the -ID& reference for local data objects. The @&*;-O)-0 addition means that a public attribute declared with ;*T* can be read from outside, but can only be changed by methods within the class. 0ou can currently only use the @&*;-O)-0 addition in the public visibility section !'3+-I# ,&#TIO)" of a class declaration or in an interface definition. 0ou can protect attributes against access from outside by characteri5ing them as private attributes !defined in the '@I:*T& ,&#TIO)". *ttributes and their values that may be used directly by an e(ternal user are public attributes and are defined in the '3+-I# ,&#TIO).

In the above e(ample for class lclEairplane, the name attribute is initially defined as a public attribute and the weight attribute is defined as a private attribute. 'ublic attributes belong to the class Ae(ternal point of contact that is, their implementation is publici5ed. If you want to hide the internal implementation from users, you must define internal and e(ternal views of attributes. *s a general rule, you should define as few public attributes as possible. There are two kinds of attributes ,tatic attributes Instance attributes Instance attributes are attributes that e(ist separately for each object. Instance attributes are defined using the ;*T* keyword. ,tatic attributes e(ist once only for each class and are visible for all !runtime" instances in that class. ,tatic attributes usually contain information that is common to all instances, such as: ;ata that is the same in all instances *dministrative information about the instances in that class !for e(ample, counters and so on" ,tatic attributes are defined using the #-*,,-;*T* keyword. 0ou may come across the e(pression $class attributes% in documentation, however, the official term in *+*' Objects !as in #//, .ava" is $static% attributes. OOPS ABAP 5 4ethods are internal procedures in classes that determine the behavior of an object. They can access all attributes in their class and can therefore change the state of an object. 4ethods have a parameter interface that enables them to receive values when they are called and pass values back to the calling program. In *+*' Objects, methods can have I4'O@TI)6, &F'O@TI)6, #=*)6I)6 and @&T3@)I)6 parameters as well as &F#&'TIO),. *ll parameters can be passed by value or reference. 0ou can define a return code for methods using @&T3@)I)6. 0ou can only do this for a single parameter, which additionally must be passed as a value. *lso, you cannot then define &F'O@TI)6 and #=*)6I)6 parameters. 0ou can define functional methods using the @&T3@)I)6 parameter !e(plained in more detail below".

*ll input parameters !I4'O@TI)6, #=*)6I)6 parameters" can be defined as optional parameters in the declaration using the O'TIO)*- or ;&2*3-T additions. These parameters then do not necessarily have to be passed when the object is called. If you use the O'TIO)*- addition, the parameter remains initiali5ed according to type, whereas the ;&2*3-T addition allows you to enter a start value. 4ethods, like attributes, must be assigned to a visibility area. This determines whether the methods can be called from outside the class or only from within the class. ,tatic methods are defined on the class level. They are similar to instance methods, but with the restriction that they can only use static components !such as static attributes" in the implementation part. This means that static methods do not need instances and can therefore be called from anywhere. They are defined using the #-*,,-4&T=O;, statement, and they are bound by the same synta( and parameter rules as instance methods. The term $class method% is common, but the official term in *+*' Objects !as in #//, .ava" is $static method%. This course uses the term $static method%. * 34- class diagram shows firstly the class name and, underneath that, the class attributes and methods. The visibility of components in a class is shown in 34- using the characters $/% and $-%: / public components - private components *lternatively, public and private can be prefi(ed to the methods. The third option for providers of modeling tools in 34- is to introduce their own symbols for visibility. @epresentation of visibility characteristics is optional and is normally only used for models that are close to implementation. ,tatic components are marked with an underscore. The method signature is represented as follows !optional": The input and output parameters and the parameters to be changed are shown in brackets. The return code is separated from the type name by a colon. * class contains the generic description of an object. It describes all the characteristics that are common to all the objects in that class. ;uring the program runtime, the class is used to create specific objects !instances". This process is called instantiation.

&(ample: The object -= +erlin is created during runtime in the main memory by instantiation from the lclEairplane class. The lclEairplane class itself does not e(ist as an independent runtime object in *+*' Objects. @eali5ation: Objects are instantiated using the statement: #@&*T& O+.&#T. ;uring instantiation, the runtime environment dynamically re1uests main memory space and assigns it to the object. ;*T*: airplane7 T0'& @&2 TO lclEairplane declares the reference variable airplane7. This acts as a pointer to an object. The #@&*T& O+.&#T statement creates an object in the main memory. The attribute values of this object are either initial values or correspond to the :*-3& entry. @eference variables can also be assigned to each other. The above e(ample shows that once it has been assigned, airplane7 points to the same object as reference airplaneG. *s soon as no more references point to an object, the 6arbage #ollector removes it from the memory. The 6arbage #ollector is a system routine that automatically deletes objects that are no longer be addressed from the main memory and releases the memory space they occupied. Independent references are references that have not been defined within a class. OOPS ABAP 6 If you want to keep several objects from the same class in your program, you can define an internal table, which might, for e(ample, only consist of one column with the object references for this class. 0ou can work with the objects using the internal table within the loop. If a class defines object references to a second class as attributes !in the above e(ample: leftEwing, rightEwing", then only these object references will be stored in the objects belonging to that class. The objects in the second class have their own identity.

'ublic attributes can be accessed from outside the class in various ways: ,tatic attributes are accessed using H?. Instance attributes are accessed using -?. &very object behaves in a certain way. This behavior is determined by its methods. There are three types of method: 7. 4ethods that cause behavior and do not pass values G. 4ethods that pass a value I. 4ethods that pass or change several values *n object that re1uires services from another object sends a message to the object providing the services. This message names the operation to be e(ecuted. The implementation of this operation is known as a method. 2or the sake of simplicity, method is used below as a synonym for operation and message. 'ublic methods can be called from outside the class in a number of ways: Instance methods are called using #*-- 4&T=O; -?. ,tatic methods are called using #*-- 4&T=O; H?. ,tatic methods are addressed by class name, since they do not need instances. )ote: If you are calling a static method from within the class, you can omit the class name. Bhen calling an instance method from within another instance method, you can omit the instance name. The method is automatically e(ecuted for the current object. 4ethods that have a @&T3@)I)6 parameter are described as functional methods. These methods cannot have &F'O@TI)6 or #=*)6I)6 parameters, but has many !or as few" I4'O@TI)6 parameters and &F#&'TIO), as re1uired. 2unctional methods can be used directly in various e(pressions !although &F#&'TIO), are not catchable at the moment - you must use the long form of the method call": in logical e(pressions !I2, &-,&I2, B=I-&, #=&#D, B*IT" in the #*,& statement !#*,&, B=&)" in the -OO' statement

in arithmetic e(pressions !#O4'3T&" in +it e(pressions !#O4'3T&" in the 4O:& statement. The synta( for instance methods !analogous to static methods" is as follows, depending on the number of I4'O@TI)6 parameters : no I4'O@TI)6 parameters: ref-?funcEmethod! " e(actly 7 I4'O@TI)6 parameter : ref-?funcEmethod! p7 " oder ref-?funcEmethod! imE7 H p7 " several I4'O@TI)6 parameters : ref-?funcEmethod! imE7 H p7 imEG H pG " The constructor is a special !instance" method in a class and is always named #O),T@3#TO@. The following rules apply: &ach class has e(actly one constructor. The constructor does not need to be defined if no implementation is defined. The constructor is automatically called during runtime within the #@&*T& O+.&#T statement. If you need to implement the constructor, then you must define and implement it in the '3+-I# ,&#TIO). Bhen &F#&'TIO), are triggered in the constructor, instances are not created !as of J.Ka", so no main memory space is taken up. 0ou need to implement the constructor when, for e(ample 0ou need to allocate !e(ternal" resources 0ou need to initiali5e attributes that cannot be covered by the :*-3& supplement to the ;*T* statement 0ou need to modify static attributes 0ou cannot normally call the constructor e(plicitly. The static constructor is a special static method in a class and is always named #-*,,E#O),T@3#TO@. It is e(ecuted precisely once per program. The static constructor of class is called automatically before the class is first accessed, that is, before any of the following actions are e(ecuted: #reating an instance in the class using #@&*T& O+.&#T obj, where obj has the data type @&2 TO . *ddressing a static attribute using H?. #alling a static attribute using #*-- 4&T=O; H?. @egistering a static event handler method using ,&T =*);-&@ H? for obj. @egistering an event handler method for a static event in class . The static constructor cannot be called e(plicitly.

&ncapsulation The principle of encapsulation is to hide the implementation of a class from other components in the system, so that these components cannot make assumptions about the internal state of the objects in that class or of the class itself. This prevents dependencies on specific implementations from arising. The class is the capsule surrounding related functions. The principle of visibility ensures that the implementation of the functions and the information administered within a class is hidden. #lasses behave like client<server systems: Bhen a class is called by a method of another class, it automatically becomes the client of the other !server" class. This creates two re1uirements : The client class must observe the protocol of the server class. The server class protocol must be clear and detailed enough that a potential client has no trouble in orienting by it. #lasses normally play both roles. &very class is a potential server class, and when it is called by a method of another class it then becomes a client class too. &stablishing logical business and software responsibilities between classes results in a true client<server software system in which redundancy is avoided. In delegation, two objects are involved in handling a re1uest: the recipient of the re1uest delegates the e(ecution of the re1uest to a delegate. &(ample: The pilot !lclEclient" calls the method getEfuelElevel from the airplane class !lclEairplane". The airplane cannot carry out this task itself. Therefore the airplane calls the getEfuelElevel method from the tank class !lclEtank", that is, the airplane delegates the e(ecution of the method to the tank. The main advantage of delegation !as a re-use mechanism" lies in the option of changing the behavior of the recipient by substituting the delegate !at runtime". 2or e(ample, delegation enables the airplane to be e1uipped with a new tank, without the call changing for the client or for the airplane class. 6ood capsulation often forces you to use delegation: if tank in the above e(ample were a private attribute in class lclEairplane, then the user cannot address the tank directly, but

only through the airplaneL

Bithin a class, attribute names, method names, event names, constant names, type names and alias names all share the same namespace. There is a local namespace within methods. ;efinitions of variables can cover components in one class. 0ou can address the object itself within object methods using the implicitly available reference variable 4&. ;escription of the e(ample: In the #O),T@3#TO@, the instance attribute name is covered by the locally defined variable name. In order to still be able to address the instance attribute, you need to use 4&. OOPS ABAP 7 Inheritance is a relationship in which one class !the subclass" inherits all the main characteristics of another class !the superclass". The subclass can also add new components !attributes, methods, and so on" and replace inherited methods with its own implementations. Inheritance is an implementation relationship that emphasi5es similarities between classes. In the e(ample above, the similarities between the passenger plane and cargo plane classes are e(tracted to the airplane superclass. This means that common components are only defined<implemented in the superclass and are automatically present in the subclasses. The inheritance relationship is often described as an $is-a% relationship: a passenger plan is an airplane. Inheritance should be used to implement generali5ation and speciali5ation relationships. * superclass is a generali5ation of its subclasses. The subclass in turn is a speciali5ation of its superclasses. The situation in which a class, for e(ample lclEM, inherits from two classes !lclEK and lclE9" simultaneously, is known as multiple inheritance. This is not reali5ed in *+*' Objects. *+*' Objects only has single inheritance. =owever, you can simulate multiple inheritance in *+*' Objects using interfaces !see the section on interfaces".

,ingle inheritance does not mean that the inheritance tree only has one level. On the contrary, the direct superclass of one class can in turn be the subclass of a further superclass. In other words: the inheritance tree can have any number of levels, so that a class can inherit from several superclasses, as long as it only has one direct superclass. Inheritance is a $one-sided relationship%: subclasses know their direct superclasses, but !super"classes do not know their subclasses.

)ormally the only other entry re1uired for subclasses is what has changed in relation to the direct superclass. Only additions are permitted in *+*' Objects, that is, in a subclass you can $never take something away from a superclass%. *ll components from the superclass are automatically present in the subclass. If inheritance is used properly, it provides a significantly better structure, as common components only need to be stored once centrally !in the superclass" and are then automatically available to subclasses. ,ubclasses also profit immediately from changes !although the changes can also render them invalidL". Inheritance provides very strong links between the superclass and the subclass. The subclass must possess detailed knowledge of the implementation of the superclass, particularly for redefinition, but also in order to use inherited components. &ven if, technically, the superclass does not know its subclasses, the subclass often makes additional re1uirements of the superclass, for e(ample, because a subclass needs certain protected components or because implementation details in the superclass need to be changed in the subclass in order to redefine methods. The basic reason is that the developer of a !super"class cannot normally predict all the re1uirements that subclasses will later need to make of the superclass. Inheritance provides an e(tension of the visibility concept: there are protected components. The visibility of these components lies between that of the public components !visible to all users, all subclasses, and the class itself", and private !visible only to the class itself". 'rotected components are visible to and can be used by all subclasses and the class itself. ,ubclasses cannot access the private components !particularly attributes" of the superclass. 'rivate components are genuinely private. This is particularly important if a !super"class needs to make local enhancements to handle errors: it can use private components to do this without knowing or invalidating subclasses. In *+*' Objects, you must keep to the section se1uence '3+-I#, '@OT&#T&;,

'@I:*T&. The constructor of the superclass must be called within the constructor of the subclass. The reason for this is the special task of the constructor: to ensure that objects are initiali5ed correctly. Only the class itself, however, can initiali5e its own !private" components correctly> this task cannot be carried out by the subclass. Therefore it is essential that all !instance" constructors are called in an inheritance hierarchy !in the correct se1uence". 2or static constructors, unlike instance constructors, the static constructor in the superclass is called automatically, that is, the runtime system automatically ensures that, before the static constructor in a particular class is e(ecuted, the static constructors of all its superclasses have already been e(ecuted. 0ou must also consider the model described for instance constructors when using #@&*T& O+.&#T. In this model, the constructor of the immediate superclass must be called before the non-inherited instance attributes can be initiali5ed. There are basically two methods of creating an instance in a class using #@&*T& O+.&#T: 7. The instance constructor for that class has been defined !and implemented". In this case, when you are using #@&*T& O+.&#T, the parameters have to be filled according to the constructor interface, that is, optional parameters may, and non-optional parameters must be filled with actual parameters. If the constructor does not have any !formal" parameters, no parameters may or can be filled. G. The instance constructor for that class has not been defined. In this case, you must search the inheritance hierarchy for the ne(t highest superclass in which the instance constructor has been defined and implemented. Then, when you are using #@&*T& O+.&#T, the parameters of that class must be filled !similarly to the first method above". If there is no superclass with a defined instance constructor, then no parameters may or can be filled. If no instance constructor has been defined for a class, then a default constructor, which is implicitly always present is used. This default constructor calls the constructor from the immediate superclass. In *+*' Objects, you can not only add new components, but also provide inherited

methods with new implementations. This is known as redefinition. 0ou can only redefine !public and protected" instance methods, other components !static methods, attributes and so on" cannot be redefined. 2urthermore, implementation is restricted to !re-"implementation of an inherited method> you cannot change method parameters !signature change". 0ou also cannot redefine a class s !instance" constructor. In 34-, the redefinition of a method is represented by listing the method again in the subclass. 4ethods !and all other components" that are inherited but not redefined are not listed in the subclass, as their presence there is clear from the speciali5ation relationship. 0ou should not confuse redefinition with $overlaying%. This describes the ability of a class to have methods with the same name but a different signature !number and type of parameters". This option is not available in *+*' Objects. The @&;&2I)ITIO) statement for the inherited method must be in the same ,&#TIO) as the definition of the original method. !It can therefore not be in the '@I:*T& ,&#TIO), since a class s private methods are not visible and therefore not redefinable in subclassesL" If you redefine a method, you do not need to enter its interface again in the subclass, but only the name of the method. The reason for this is that *+*' Objects does not support overlaying !see notes to previous slide". To implement a redefined method in a subclass, you often need to call the method of the same name in the immediate superclass. In *+*' Objects you can call the method from the superclass using the pseudo-reference super: #*-- 4&T=O; super?methodEname.The pseudo-reference super can only be used in redefined methods. OOPS ABAP 8 One of the significant principles of inheritance is that an instance from a subclass can be used in every conte(t in which an instance from the superclass appears. This is possible because the subclass has inherited all components from the superclass and therefore has the same interface as the superclass. The user can therefore address the subclass instance in the same way as the superclass instance. :ariables of the type $reference to superclass% can also refer to subclass instances at runtime. The assignment of a subclass instance to a reference variable of the type $reference to superclass% is described as a narrowing cast, because you are switching from a view with

more detail to a view with less detail. The description $up-cast% is also used. Bhat is a narrowing cast used forC * user who is not interested in the finer points of cargo or passenger planes !but only, for e(ample, in the tank gauge" does not need to know about them. This user only needs to work with !references to" the lclEairplane class. =owever, in order to allow the user to work with cargo or passenger planes, you would normally need a narrowing cast. *fter the narrowing cast you can use the airplane reference to access the components of the cargo plane instance that were inherited from lclEairplane, obviously in some cases with the limitations entailed by their visibility. 0ou can no longer access the cargo-planespecific part of the instance !cargo in the above e(ample" using the airplane reference. * reference variable always has two types: static and dynamic: The static type of a reference variable is determined by variable definition using T0'& @&2 TO. It cannot and does not change. It establishes which attributes and methods can be addressed The dynamic type of a reference variable is the type of the instance currently being referred to, it is therefore determined by assignment and can change during the program run. It establishes what coding is to be e(ecuted for redefined methods. In the e(ample, the static type of the airplane variable is always A@&2 TO lclEairplane , but its dynamic type after the cast is A@&2 TO lclEcargoEairplane . The reference 4& can be used to determine the dynamic type in the ;ebugger. The type of case described above is known as a widening cast because it changes the view to one with more details. The instance assigned !a cargo plane in the above e(ample" must correspond to the object reference !cargoEairplane in the above e(ample", that is, the instance must have the details implied by the reference. This is also known as a $down cast%. The widening cast in this case does not cause an error because the reference airplane actually points to an instance in the subclass lclEcargoEairplane. The dynamic type is therefore A@&2 TO lclEcargoEairplane .

=ere the widening cast produces the 4O:&E#*,TE&@@O@ runtime error that can be caught with $#*T#= ... &);#*T#=%, because the airplane reference does not point to an instance in the subclass lclEcargoEairplane, but to a $general airplane object%. Its dynamic type is therefore A@&2 TO lclEairplane and does not correspond to the reference type cargoEairplane.

The widening cast logically represents the opposite of the narrowing cast. The widening cast cannot be checked statically, only at runtime. The #ast Operator $CH% !or the e1uivalent $4O:& ... CTO N%" must be used to make this visible. Bith this kind of cast, a check is carried out at runtime to ensure that the current content of the source variable corresponds to the type re1uirements of the target variables. In this case therefore, it checks that the dynamic type of the source reference airplane is compatible with the static type of the target reference cargoEairplane. If it is, the assignment is carried out. Otherwise the catchable runtime error $4O:&E#*,TE&@@O@% occurs, and the original value of the target variable remains the same. * subclass instance can be used in any conte(t in which a superclass instance also appears. 4oreover: the user does not and is not intended to know whether he<she is dealing with a subclass or a superclass. The user therefore works only with references to the superclass and must rely on the inherited components behaving in the subclass instances e(actly as they do in the superclass instances, otherwise the program will not workL On the other hand, this ensures useful restrictions on the implementation of the subclasses: inherited components must keep their inherited semantics. 0ou cannot use inherited attributes or events in any way other than intended in the superclass, and you cannot change method semantics by redefinitionL 0ou must avoid coding inheritance: it is not correct for one class to inherit from another simply because part of the functionality re1uired is already implemented there.

OOPS ABAP 9
CAST: One of the significant principles of inheritance is that an instance from a subclass can be used in every context in which an instance from the superclass appears. This is possible because the subclass has inherited all components from the superclass and therefore has the same interface as the superclass. The user can therefore address the subclass instance in the same way as the superclass instance.

Variables of the type reference to superclass! can also refer to subclass instances at runtime. The assignment of a subclass instance to a reference variable of the type reference to superclass! is described as a narrowing cast" because you are switching from a view with more detail to a view with less detail. The description up#cast! is also used. $hat is a narrowing cast used for% A user who is not interested in the finer points of cargo or passenger planes &but only" for example" in the tan' gauge( does not need to 'now about them. This user only needs to wor' with &references to( the lcl)airplane class. *owever" in order to allow the user to wor' with cargo or passenger planes" you would normally need a narrowing cast. After the narrowing cast you can use the airplane reference to access the components of the cargo plane instance that were inherited from lcl)airplane" obviously in some cases with the limitations entailed by their visibility. +ou can no longer access the cargo#plane#specific part of the instance &cargo in the above example( using the airplane reference. A reference variable always has two types: static and dynamic: The static type of a reference variable is determined by variable definition using T+,- .-/ TO. 0t cannot and does not change. 0t establishes which attributes and methods can be addressed The dynamic type of a reference variable is the type of the instance currently being referred to" it is therefore determined by assignment and can change during the program run. 0t establishes what coding is to be executed for redefined methods. 0n the example" the static type of the airplane variable is always 1.-/ TO lcl)airplane2" but its dynamic type after the cast is 1.-/ TO lcl)cargo)airplane2. The reference 3- can be used to determine the dynamic type in the 4ebugger.

The type of case described above is 'nown as a widening cast because it changes the view to one with more details. The instance assigned &a cargo plane in the above example( must correspond to the ob5ect reference &cargo)airplane in the above example(" that is" the instance must have the details implied by the reference. This is also 'nown as a down cast!. The widening cast in this case does not cause an error because the reference airplane actually points to an instance in the subclass lcl)cargo)airplane. The dynamic type is therefore 1.-/ TO lcl)cargo)airplane2. *ere the widening cast produces the 3OV-)CAST)-..O. runtime error that can be caught with CATC* ... -64CATC*!" because the airplane reference does not point to an instance in the subclass lcl)cargo)airplane" but to a general airplane ob5ect!. 0ts dynamic type is therefore 1.-/ TO lcl)airplane2 and does not correspond to the reference type cargo)airplane. The widening cast logically represents the opposite of the narrowing cast. The widening cast cannot be chec'ed statically" only at runtime. The Cast Operator %7! &or the e8uivalent 3OV- ... %TO 9!( must be used to ma'e this visible. $ith this 'ind of cast" a chec' is carried out at runtime to ensure that the current content of the source variable corresponds to the type re8uirements of the target variables. 0n this case therefore" it chec's that

the dynamic type of the source reference airplane is compatible with the static type of the target reference cargo)airplane. 0f it is" the assignment is carried out. Otherwise the catchable runtime error 3OV-)CAST)-..O.! occurs" and the original value of the target variable remains the same. A subclass instance can be used in any context in which a superclass instance also appears. 3oreover: the user does not and is not intended to 'now whether he:she is dealing with a subclass or a superclass. The user therefore wor's only with references to the superclass and must rely on the inherited components behaving in the subclass instances exactly as they do in the superclass instances" otherwise the program will not wor'; On the other hand" this ensures useful restrictions on the implementation of the subclasses: inherited components must 'eep their inherited semantics. +ou cannot use inherited attributes or events in any way other than intended in the superclass" and you cannot change method semantics by redefinition; +ou must avoid coding inheritance: it is not correct for one class to inherit from another simply because part of the functionality re8uired is already implemented there. OOPS ABAP 10 ,O<+3O.,*0S3 : Ob5ects from different classes &lcl)cargo)airplane and lcl)passenger)airplane in the above example ( can be stored in an internal table consisting of references to the superclass &lcl)airplane in the above example" and then processed identically &polymorphically( &see next slide(. $hat coding is actually executed when estimate)fuel)consumption is called depends on the dynamic type of the plane reference variable" that is" it depends on which ob5ect from which &sub(class plane points to. +ou can use polymorphism to write programs that are generic to a high degree and that do not even need to be changed if use cases are added. 0n the simple example above" this means that" should a further subclass be added" for example" for airplanes that fly in space" the above coding would not need to be changed. =sing polymorphism ma'es generic programming easier. 0nstead of implementing a CAS- or 0/ statement" you can have one access or call" which improves readability and does not need to be changed if you extend the program by adding further subclasses. /=.T*-. C*A.ACT-.ST0CS O/ 06*-.0T-6C- : +ou cannot instantiate ob5ects in an abstract class. This does not" however" mean that references to such classes are meaningless. On the contrary" they are very useful" since they can &and must( refer to instances in subclasses of the abstract class during runtime. The C.-AT-#O>?-CT statement is extended in this context. +ou can enter the class of the instance to be created explicitly: C.-AT- O>?-CT T+,- . Abstract classes are normally used as an incomplete blueprint for concrete &that is" non#abstract( subclasses" in order to define a uniform interface" for example. Abstract instance methods are used to specify particular interfaces for subclasses" without having to immediately provide implementation for them. Abstract methods need to be redefined and thereby implemented in the subclass &here you also need to include the corresponding redefinition statement in the 4-/060T0O6 part of the subclass(. Classes with at least one abstract method are themselves abstract Static methods and constructors cannot be abstract &they cannot be redefined(.

A final class cannot have subclasses" and can protect itself in this way against &uncontrolled( speciali@ation. A final method in a class cannot be redefined in a subclass" and can protect itself in this way against &uncontrolled( redefinition. Some characteristics: A final class implicitly only contains final methods. +ou cannot enter /06A< explicitly for these methods in this case. 3ethods cannot be both final and abstract. Classes" on the other hand" can usefully be both abstract and final: only static components can be used there. 0n A>A, Ob5ects" all static components in an inheritance relationship are shared. /or attributes this means that each static attribute only exists once per roll area. 0n this way a class that defines a public or protected static attribute shares this attribute with all its subclasses. The significant point here is that subclasses do not each receive their own copy of the static attribute. Shared static methods cannot be redefined in subclasses. *owever" you can call inherited &public or protected( static methods using subclasses. Adding private components is never a problem. Adding public or protected components to a class can however invalidate that class2s subclasses" if they already contain components with the same name. $hen you add that component" you get the syntax error message that that component has already been declared. =sing inheritance instead of attributes" or a misunderstanding of inheritance as an is#one! relationship often leads to the following 'ind of design: the superclass car! has the subclasses red car!" green car!" and so on. These subclasses all have an identical structure and identical behavior. As an instance cannot change its class" in circumstances li'e the following" you should not use inheritance directly" but use additional attributes to differentiate between cases &see appendix(: The class employee! has the subclasses full#time employee! and part#time employee!. $hat happens when a part#time employee becomes a full#time employee% A new full#time#employee ob5ect would have to instantiated and all the information copied from the part#time#employee ob5ect. *owever" users who still have a reference to the part#time#employee instance would then be wor'ing with a part#time#employee ob5ect that logically does not exist anymore; The use of inheritance does not always correspond to expectations in the real world: for example" if the class 1s8uare2 inherits from the class 1rectangle2" the latter will have two separate methods for changing length and width" although the sides of the s8uare actually need to be changed by the same measurement.

OOPS ABAP 11 06T-./AC-S : 0n A>A, Ob5ects" interfaces are implemented in addition to and independently of classes. 0nterfaces exclusively describe the external point of contact of a class" but they do not contain their own implementation part. 0nterfaces are usually defined by a user. The user describes in the interface which services &technical and semantic( it needs in order to carry out a tas'. The user never actually 'nows the providers" but communicates with them through the interface. 0n this way the user is protected from actual implementations and can wor' in the same way with different classes:ob5ects" as long as they provide the services re8uired &this is polymorphism using interfaces(. The above example shows two users: the document library and the file browser. >oth define the tas's that

potential providers must be able to carry out: display and print in the first case and show a node for the file folder display in the second. Various providers &plain text files" spreadsheets( can perform all the services re8uired" but one provider &the folder( can only perform the service re8uired by the /ile >rowser and can therefore not be used by the 4ocument <ibrary.

0n =3<" interfaces can represented in the same way as classes. *owever" they always have stereotype AinterfaceB above their name and can therefore be told apart from classes. The use of an interface is represented by a dotted line with a two#sided arrow from the user to the interface" the stereotype AusesB is optional. The fact that a class implements an interface is represented by a dotted line with a three#sided arrow from the class to the interface. The similarity to the representation of inheritance is intentional" as the interface can be seen as a generali@ation of the class implemented or the class can be seen as a speciali@ation of the interface. 0n A>A, Ob5ects" the same components can be defined in interfaces and in classes. This allows you to shift part of the public point of contact of a class into an interface" even though the class is already in useC users will not notice the difference as long as you use alias names &see appendix( for the components that are now in the interface. A class can implement any number of interfaces and an interface can be implemented by any number of classes. 0n A>A, Ob5ects" the same components &attributes" methods" constants" types" alias names( can be defined in an interface in largely the same way as in classes. *owever" interfaces do not have component visibility sections. 0nterfaces are implemented in classes. The interface name is listed in the definition part of the class. 0nterfaces can only be implemented 1publicly2 and are therefore always in the ,=><0C S-CT0O6 &this is only valid as of .elease D.E(. 0f you do not do this" you ris' multiple implementations" if a superclass and a subclass both implement the same interface privately. The operations defined in the interface are implemented as methods of a class. A chec' is carried out to ensure that all the methods defined in the interfaces are actually present in the implementation part of the class &for global interfaces" a missing or superfluous implementation of an interface method results in a To4o warning(. The attributes" events" constants and types defined in the interface are automatically available to the class carrying out the implementation. 0nterface components are addressed in the class carrying out the implementation by prefixing the interface name" followed by a tilde &the 0nterface .esolution Operator(: F.

The interface resolution operator enables you to access interface components using 0n ob5ect reference belonging to the class implementing the interface in exactly the same way as the method definition in the implementation part of the class. This allows you to differentiate between components defined in the interface and components of the same name that are defined in the class itself. This is caused by the shared namespace. 0nterfaces are addressed using interface references. 0nterface references always refer to instances in the classes carrying out the implementation. 0nterface references therefore always have both static and dynamic types. The assignment of an ob5ect reference to an interface reference is 'nown as a narrowing cast since" as with inheritance" only a part of the ob5ect interface is visible once you have assigned the reference.

$ith an interface reference" you can no longer address all components in the class carrying out the implementation" but only the components defined in the interface. These components are now addressed using the interface reference exclusively with their own 1short2 name; $hen an ob5ect reference is assigned to an interface reference" the static types 3ust be convertible" that is" the class that was used to define the ob5ect reference must have implemented the interface#reference interface. Otherwise there will be a syntax error. The widening cast is" as with inheritance" the opposite of the narrowing cast: here it is used to retrieve an ob5ect reference from an interface reference. Obviously it cannot be statically chec'ed" since an interface can be implemented by more than one class. An ob5ect reference cannot be assigned to an interface reference if it has itself not implemented the corresponding interface. 0t cannot be assigned even if a subclass has implemented the interface and the interface reference points to an ob5ect in this class. Assignments between interface references whose interfaces are not related to each other cannot be chec'ed statically and must therefore be formulated using the cast operator %7!. /or this type of assignment" a chec' must be carried out at runtime to see whether the class of the instance that the source reference points to also supports the interface that the target reference refers to. 0f this is the case" the cast is carried out" otherwise the catchable runtime 3OV-)CAST)-..O. occurs. This type of cast is neither a widening nor a narrowing cast" rather a switch from one view of an ob5ect to another. ,olymorphism can also be used for interfaces: you can use interface references to call methods that can have a different implementation depending on the ob5ect behind the reference. The dynamic type" not the static type of the reference variable is used to search for the implementation of a method. CA<< 3-T*O4 document#Gdisplay above therefore uses the class of the instance that document actually refers to to search for the implementation of display. The static type for document" which is always 1.-/ TO lif)doc2 is not used. 0f you want to write polymorphic programs" you must first decide how the ob5ects that you want to wor' with are related to each other. 0f the ob5ects are dependent on each other through inheritance" then choose polymorphism and inheritance. *owever" if the ob5ects are not directly related to each other" but simply 1happen2 to have the same characteristics" then use interfaces to achieve polymorphism. OOPS ABAP 12 CO3,O=64 06T-./AC- : Changes to an interface usually invalidate all the classes implementing it. A>A, Ob5ects contains a composition model for interfaces. A compound interface contains other interfaces as components &component interfaces( and is therefore a summari@ed extension of these component interfaces. An elementary interface does not itself contain other interfaces. One interface can be used as a component interface in several compound interfaces. =3< only deals with the speciali@ation:generali@ation of interfaces. This relationship is represented by a dotted line with a three#sided arrow from the speciali@ed to the generali@ed interface. Compound interfaces in A>A, Ob5ects can always be seen as speciali@ations of their component interfaces and represented as such in =3<.

0n a compound interface" the components of the component interface 'eep their original names" that is FC no more prefixes are added; 0n other words: all components in a compound interface are on the same level" and components inherited from component interfaces are mar'ed with the usual interface prefix. This 1e8uality principle2 for compound interfaces also affects how they are implemented. The procedure is as follows: first you implement the elementary interfaces" then the additional methods from the compound interfaces. /or multiple compound interfaces" the process is simply repeated. 0n the class carrying out the implementation" all components of all interfaces implemented are again on the same level. This means that interface components only ever exist once and are 'nown by their original names F. This is true both for compound interfaces and for the classes that implement them. 0nterfaces are the means of choice for describing external points of contact" without lin'ing them to a type of implementation. An extra layer is introduced between the client and the server to protect the client explicitly from the server" thereby ma'ing it much more independent; 0nterfaces enable you to wor' uniformly with different classes &providers(. 0n particular" they always ensure polymorphic behavior as they do not have their own implementation" but instead allow the providers to carry it out. The definition of an interface is always an abstraction: the user wants to handle various providers in the same way and must therefore abstract concrete implementations to a description of the services re8uired to fulfill the tas'. +ou can also use interfaces to achieve multiple inheritance by defining the functionality to be inherited by a second class as an interface that the inheriting class then has to implement. OOPS ABAP 13 -V-6TS : >y triggering an event" an ob5ect or a class announces a change of state" or that a certain state has been achieved. 0n the above example" the airplane class triggers the event 1touched)down2. Other classes subscribe to this event and process it. The air#traffic controller mar's the plane as landed on the list" the pilot breathes a sigh of relief and the passenger" 3r. 3iller" applauds. 6ote: The events discussed here are not A>A, events such as 060T0A<0HAT0O6" STA.T#O/#S-<-CT0O6" and so on.

-vents lin' ob5ects or classes more loosely than direct method calls do. 3ethod calls establish precisely when and in which statement se8uence the method is called. *owever" with events" the reaction of the ob5ect to the event is determined by the triggering of the event itself. -vents are most often used in I=0 implementations. Other external ob5ect models" such as CO3" ActiveJ Controls etc" also provide events. At the moment of implementation" a class defines its instance events &using the statement -V-6TS( and static events &using the statement C<ASS#-V-6TS( Classes or their instances that receive a message when an event is triggered at runtime and want to react to this event define event handler methods.

Statement : &C<ASS#(3-T*O4S /O. -V-6T O/ . These classes or their instances register themselves at runtime to one or more -vents. Statement : S-T *A64<-. /O. . &for instance events( S-T *A64<-. . &for static events(. A class or an instance can trigger an event at runtime using the statement .A0S- -V-6T. >oth instance and static events can be triggered in instance methods. Only static events can be triggered in static methods. -vents can only have -J,O.T06I parameters which must be passed by value. Triggering an event using the statement .A0S- -V-6T has the following effect: the program flow is interrupted at that point the event handler methods registered to this event are called and processed once all event handler methods have been executed" the program flow starts again. 0f an event handler method in turn triggers an event" then the program flow is again interrupted and all event handler methods are executed &nesting(.

-vents are registered using the command S-T *A64<-.. .egistration is only active at program runtime. -vents cannot be persistent. +ou want to register an ob5ect to an event belonging to another ob5ect. The S-T *A64<-.... statement enters the registration in that ob5ect2s list. All handlers for one event are entered in this list. $hen the event is triggered" the list shows which event handler methods need to be called. -vent handler methods are triggered by events &.A0S- -V-6T(" although they can also be called li'e normal methods &CA<< 3-T*O4(. The interface of the event handler method consists solely of 03,O.T06I parameters. Only parameters from the definition of the corresponding event &event interface( can be used. An event interface only has -J,O.T06I parameters and is defined using the -V-6TS statement in the declaration of the event. The parameters are typed in the event definition and the typing is passed to the event handler method" that is" the interface parameters of the event handler method cannot be typed in the definition of the event handler method. 0n addition to the explicitly defined event interface parameters" the implicit parameter S-64-. can also be listed as an 03,O.T06I parameter for instance events. This passes on a reference to the ob5ect that triggered the event. $hen an event is triggered" only those event handler methods that have registered themselves using S-T *A64<-. by this point at runtime are executed. +ou can register an event using Activation 1J1 &see above example(" and deregister it using Activation 1S,AC-1 &see next slide(. +ou can also register and deregister using a variable , which is filled with one of these two values. If you do not specify a value for Activation, then the event is registered (default setting). You can register several methods in one SET !A"#$E% statement& SET !A"#$E% ' ...

' ()% * ()% A$$ I"STA"+ES.

Every o,-ect that has defined events has an internal ta,le& the handler ta,le. All o,-ects that have registered for events are entered in this ta,le together with their event handler methods. ),-ects that have registered themselves for an event that is still .live/ also remain .live/. The methods of these o,-ects are called when the event is triggered, even if they can no longer ,e reached using main memory references.

If several o,-ects have registered themselves for an event, then the se0uence in which the event handler methods are called is not defined, that is, there is no guaranteed algorithm for the se0uence in which the event handler methods are called. If a new event handler is registered in an event handler method for an event that has -ust ,een triggered, then this event handler is added to the end of the se0uence and is then also e1ecuted when its turn comes. If an e1isting event handler is deregistered in an event handler method, then this handler is deleted from the event handler method se0uence.

Events are also su,-ect to the visi,ility concept and can therefore ,e either pu,lic, protected or private. 2isi,ility esta,lishes authori3ation for event handling all users only users within that class or its su,classes only users in that class. Event handler methods also have visi,ility characteristics. Event handler methods, however, can only have the same visi,ility or more restricted visi,ility than the events they refer to. The visi,ility of event handler methods esta,lishes authori3ation for SET !A"#$E% statements& SET !A"#$E% statements can ,e made anywhere in that class and its su,classes only in that class OOPS ABAP 14 I<O>A< C<ASS-S:06T-./AC-S: <ocal classes:interfaces are only 'nown within the program in which they are defined and implemented. <ocal classes:interfaces are not stored in the .epository &no TA40. entry(. There is no global! access to these classes:interfaces &for example" from other programs(. 0f a local class is implemented in an include which is then embedded in two different programs" then references to the same! class still cannot be exchanged at runtime. Two classes that do not conform to type are created at runtime. =nli'e local in program classes:interfaces" global classes:interfaces can be created and implemented using the A>A, $or'bench Tool Class >uilder or transaction S-KD. These classes:interfaces are then available to

all developers. Ilobal class and interface names share the same namespace. Ilobal classes:interfaces have a TA40. entry: .LT. C<ASS The smallest transport unit is method <03= 3-T*.

The Class >uilder is a tool in the A>A, $or'bench that is used to create" define and test global A>A, classes and interfaces. 0n the initial screen" select the ob5ect type you want to wor' with # class or interface. Then choose one of the display" change" create or test functions. 0n the initial screen you have the choice of viewing the contents of the .:L class library using the Class >rowser or going straight to basic data maintenance of the ob5ect types and the Class -ditor" where you can define the ob5ect types and their components. The ob5ect type definition can be immediately followed by method implementation in the A>A, -ditor. +ou can also access the test environment from the initial screen or from the Class -ditor. 0n the Class >uilder you have the same options for creating a global class as for creating a local class. OOPS ABAP 15 S=33A.+ A64 O=T<OOM : 0n the early stages of programming history" in the NOPQs and NORQs" the principle aim was to write programs that were correct and robust. A program is considered correct if it does exactly what is said in the program specification. A program is considered robust if it can react appropriately to &user( errors and does not 5ust crash immediately. As programs grew in scope and complexity" more attention began to be paid to the possibilities of extensibility and re#usability" in order to avoid constantly having to re#invent the wheel. -xtensibility is the facility to enhance an existing program by adding new functions" while still using it in the same context. .e#usability" on the other hand" is when a program or part of a program is ta'en out of its own context and recycled in another context" that is" as part of another program that has different tas's. The >usiness Ob5ect .epository" the ob5ect#oriented view of the .:L System" will be migrated to the Class <ibrary by .elS.Q. Then classes" such as customer or invoice" will be available globally in the system for use by any application. C.-AT- ,=><0C" the optional default supplement" allows unrestricted instantiation of ob5ects in a class" that is" instances in a class can be created in any part of this program:class. C.-AT- ,.OT-CT-4 only allows ob5ects in a class to be instantiated in that class itself and in any of its subclasses. C.-AT- ,.0VAT- only allows ob5ects in a class to be instantiated in that class itself. This is then done using static methods &'nown as /actory 3ethods(. -xample using the addition C.-AT- ,.0VAT- &see above(: Class lcl)manager wants to prevent several ob5ects of this class existing at runtime. Only one instance is to

be instantiated. Therefore the class defines the instantiation of ob5ects as private and provides in its place the static method get)instance" which a potential client can use to get a reference to the sole ob5ect. The C.-AT- O>?-CT statement is extended by the introduction of inheritance and interfaces: you can enter the class of the instance to be created either statically" using the class name" or dynamically" using a variable containing the class name. Once the statement has been executed &successfully(" a &runtime( instance of the class entered will have been created and the reference variable entered points to this instance. There are two possible situations: /or a reference variable referring to a class" enter the name of a subclass &or of the class itself(. /or a reference variable referring to an interface" enter the name of the class carrying out the implementation. A chec' can be carried out in the static form ... T+,- 9! to see if one of the two situations above has occurred. 0f it has not" a syntax error will occur. 0n the dynamic form ...T+,- &(.! the classname)string field provides the class name. A chec' can be carried out at runtime to ensure that the reference variable type is compatible with the class entered. 0f this is not the case" a runtime error occurs. 0n the dynamic form" you can only enter the names of classes whose &instance( constructor either has no parameters or only optional parameters. 0f the line type of an internal table contains references variables in the component comp" their attributes can accessed in the following statements: <OO, AT itab ... $*-.- comp#Gattr ... .-A4 TA><- itab ... $0T* TTA><-U M-+ comp#Gattr ... SO.T itab >+ comp#Gattr ... 4-<-T- itab $*-.- comp#Gattr ... 3O40/+ itab ... T.A6S,O.T06I .. $*-.- comp#Gattr ... 0f an internal table has unstructured lines of the reference variable type" then the attributes of the ob5ect that the line points to can be addressed using TA><-)<06-#Gattr. 0n the class carrying out the implementation" you can assign an alias name to an interface component using the A<0AS-S statement for the class itself and all its users. This is however only an abbreviation of the long name. -ven if an alias is assigned for an interface method" the method only needs to be implemented once as F. Alias names are sub5ect to the usual visibility rules. The most important use for alias names is in nested interfaces. 0n the definition of a nested interface" the components of the component interfaces cannot be addressed directly" but only using their alias names. Alias names can be used in classes to enable class#specific components that have been replaced by components from interfaces during the course of the development cycle to continue to be addressed by their old names. This means that the users of the class to not need to be ad5usted in accordance with the new names. Alias names cannot be used in the 03,<-3-6TAT0O6 part of the class itself.

A subclass always co#inherits the supported interfaces from its superclass" but does have the options of implementing additional interfaces and redefining inherited interface methods. 0f the subclass supports a compound interface" one of whose component interfaces is already implemented in the superclass" then the subclass does not need to do anything about the implementation of the component interface" but simply inherits its implementation &as long as there are no A>ST.ACT constructs involved(. 0n this case it would only need to implement the additional methods of the compound interface" although it could also redefine methods from the component interface. The principle that interface components are only present once in any one class or interface is still valid. 0n the situation described above" it is therefore irrelevant" whether the subclass is supporting the interface method because it is implementing a compound interface" or because the superclass is implementing a component interface. The uni8ue F names of interface components ensure that interface components that are 1inherited2 in a variety of ways can always be correctly identified and distinguished from one another.

Static events can be triggered in instance methods and in static methods. Classes or their instances that want to receive a message if an event is triggered and react to this event define event handler methods Statement: &C<ASS#(3-T*O4S /O. -V-6T O/ . This class or its instances register themselves for one or more events at runtime. Statement: S-T *A64<-. . At runtime a class:instance can trigger a static event using the .A0S- -V-6T statement. Static events" li'e attributes" only exist once per roll area. 0t is not the case that every subclass has its own copy of the static event. All registrations for an event therefore refer to a single event" even if the event handler method registered is defined with reference to the inherited static event of a subclass. Conse8uently" triggering a static event" be it in the defining class or in a subclass" activates all current handlers for this event" and not 5ust those that are defined with reference to a specific class.

A64 T*0S 0S T*- -64 O/ T*0S S-.0-S. Public attributes ,ublic attributes are defined in the ,=><0C section and can be viewed and changed from outside the class. There is direct access to public attributes. As a general rule" as few public attributes should be defined as possible. ,=><0C S-CT0O6. 4ATA: Counter type i. Private attributes ,rivate attributes are defined in the ,.0VAT- section. The can only be viewes and changed from within the class. There is no direct access from outside the class. ,.0VAT- S-CT0O6. 4ATA: name&KS( T+,- c" planetype <0M- saplane#planetyp" Instance attributes There exist one instance attribute for each instance of the class" thus they exist seperately for each ob5ect. 0nstance attributes are declared with the 4ATA 'eyword.

Static attributes Static attributes exist only once for each class. The data are the same for all instances of the class" and can be used e.g. for instance counters. Static attributes are defined with the 'eyword C<ASS#4ATA. ,.0VAT- S-CT0O6. C<ASS#4ATA: counter type i" Public methods Can called from outside the class ,=><0C S-CT0O6. 3-T*O4S: set)attributes 03,O.T06I p)name&KS( T+,- c" p)planetype <0M- saplane#planetyp" Private methods Can only be called from inside the class. They are placed in the ,.0VAT- section of the class. Constructor method 0mplicitly" each class has an instance constructor method with the reserved name constructor and a static constructor method with the reserved name class)constructor. The instance constructor is executed each time you create an ob5ect &instance( with the C.-AT- O>?-CT statement" while the class constructor is executed exactly once before you first access a class. The constructors are always present. *owever" to implement a constructor you must declare it explicitly with the 3-T*O4S or C<ASS#3-T*O4S statements. An instance constructor can have 03,O.T06I parameters and exceptions. +ou must pass all non#optional parameters when creating an ob5ect. Static constructors have no parameters. Static constructor The static constructor is always called C<ASS)CO6ST.=CT-." and is called autmatically before the clas is first accessed" that is before any of the following actions are executed: Creating an instance using C.-AT-)O>?-CT Adressing a static attribute using VclassnameG#GVattrbuteG Calling a ststic attribute using CA<< 3-T*O4 .egistering a static event handler .egistering an evetm handler method for a static event The static constructor cannot be called explicitly. Protected components $hen we are tal'ing subclassing and enheritance there is one more component than ,ublic and ,rivate" the ,rotected component. ,rotected components can be used by the superclass and all of the subclasses. 6ote that Subclasses cannot access ,rivate components. Polymorphism ,olymorphism: $hen the same method is implemented differently in different classes. This can be done using enheritance" by redefining a method from the superclass in subclasses and implement it differently.

OOPS Interview Questions

1) Explain the rationale behind Object Oriented concepts? Object oriented concepts form the base of all modern programming languages. Understanding the basic concepts of object-orientation helps a developer to use various modern day programming languages, more effectively. 2) Explain about Object oriented programming? Object oriented programming is one of the most popular methodologies in software development. t offers a powerful model for creating computer programs. t speeds the program development process, improves maintenance and enhances reusability of programs. !) Explain what is an object? "n object is a combination of messages and data. Objects can receive and send messages and use messages to interact with each other. #he messages contain information that is to be passed to the recipient object. $) Explain the implementation phase with respect to OOP? #he design phase is followed by OO%, which is the implementation phase. OO% provides

specifications for writing programs in a programming language. &uring the implementation phase, programming is done as per the re'uirements gathered during the analysis and design phases. () Explain about the Design Phase? n the design phase, the developers of the system document their understanding of the system. &esign generates the blue print of the system that is to be implemented. #he first step in creating an object oriented design is the identification of classes and their relationships. )) Explain about a class? *lass describes the nature of a particular thing. +tructure and modularity is provided by a *lass in object oriented programming environment. *haracteristics of the class should be understandable by an ordinary non programmer and it should also convey the meaning of the problem statement to him. *lass acts li,e a blue print. -) Explain about instance in object oriented programming? .very class and an object have an instance. nstance of a particular object is created at runtime. /alues defined for a particular object define its +tate. nstance of an object e0plains the relation ship between different elements. 1) Explain about inheritance? nheritance revolves around the concept of inheriting ,nowledge and class attributes from the parent class. n general sense a sub class tries to ac'uire characteristics from a parent class and they can also have their own characteristics. nheritance forms an important concept in object oriented programming. 2) Explain about multiple inheritance? nheritance involves inheriting characteristics from its parents also they can have their own characteristics. n multiple inheritance a class can have characteristics from multiple parents or classes. " sub class can have characteristics from multiple parents and still can have its own characteristics. 13) Explain about encapsulation? .ncapsulation passes the message without revealing the e0act functional details of the class. t allows only the relevant information to the user without revealing the functional mechanism through which a particular class had functioned. 11) Explain about abstraction? "bstraction simplifies a comple0 problem to a simpler problem by specifying and modeling the class to the relevant problem scenario. t simplifies the problem by giving the class its specific class of inheritance. *omposition also helps in solving the problem to an e0tent. 12) Explain the mechanism of composition? *omposition helps to simplify a comple0 problem into an easier problem. t ma,es different classes and objects to interact with each other thus ma,ing the problem to be solved automatically. t interacts with the problem by ma,ing different classes and objects to send a message to each other. 1!) Explain about polymorphism? %olymorphism helps a sub class to behave li,e a parent class. 4hen an object belonging to different data types respond to methods which have a same name, the only condition being that those methods should perform different function. 1$) Explain about overriding polymorphism? Overriding polymorphism is ,nown to occur when a data type can perform different functions. 5or e0ample an addition operator can perform different functions such as addition, float addition etc. Overriding polymorphism is generally used in comple0 projects where the use of a parameter is more. 1() Explain about object oriented databases? Object oriented databases are very popular such as relational database management systems. Object oriented databases systems use specific structure through which they e0tract data and they combine the data for a specific output. #hese &67+ use object oriented languages to ma,e the process easier. 1)) Explain about parametric polymorphism? %arametric polymorphism is supported by many object oriented languages and they are very

important for object oriented techni'ues. n parametric polymorphism code is written without any specification for the type of data present. 8ence it can be used any number of times. 1-) What are all the languages which support OOP? #here are several programming languages which are implementing OO% because of its close pro0imity to solve real life problems. 9anguages such as %ython, :uby, :uby on rails, %erl, %8%, *oldfusion, etc use OO%. +till many languages prefer to use &O7 based languages due to the ease in coding. --------1) Explain what is object oriented programming language? Object oriented programming language allows concepts such as modularity, encapsulation, polymorphism and inheritance. +imula is credited to be the first object oriented language. Objects are said to be the most important part of object oriented language. *oncept revolves around ma,ing simulation programs around an object. 2) ame some languages which have object oriented language and characteristics? +ome of the languages which have object oriented languages present in them are "6"%, .*7" +cript, *;;, %erl, 9 +%, *<, #cl, /6, :uby, %ython, %8%, etc. %opularity of these languages has increased considerably as they can solve comple0 problems with ease. !) Explain about !"#? U79 or unified modeling language is regarded to implement complete specifications and features of object oriented language. "bstract design can be implemented in object oriented programming languages. t lac,s implementation of polymorphism on message arguments which is a OO%s feature. $) Explain the meaning of object in object oriented programming? 9anguages which are called as object oriented almost implement everything in them as objects such as punctuations, characters, prototypes, classes, modules, bloc,s, etc. #hey were designed to facilitate and implement object oriented methods. () Explain about message passing in object oriented programming? 7essage passing is a method by which an object sends data to another object or re'uests other object to invo,e method. #his is also ,nown as interfacing. t acts li,e a messenger from one object to other object to convey specific instructions. )) $tate about %ava and its relation to Object oriented programming? =ava is widely used and its share is increasing considerably which is partly due to its close resemblance to object oriented languages such as * and *;;. *ode written in =ava can be transported to many different platforms without changing it. t implements virtual machine. -) What are the problems faced by the developer using object oriented programming language? #hese are some of the problems faced by the developer using object oriented language they are> 1) Object oriented uses design patterns which can be referred to as anything in general. 2) :epeatable solution to a problem can cause concern and disagreements and it is one of the major problems in software design. 1) $tate some of the advantages of object oriented programming? +ome of the advantages of object oriented programming are as follows> 1) " clear modular structure can be obtained which can be used as a prototype and it will not reveal the mechanism behind the design. t does have a clear interface. 2) .ase of maintenance and modification to the e0isting objects can be done with ease. !) " good framewor, is provided which facilitates in creating rich ?U applications. 2) Explain about inheritance in OOP$? Objects in one class can ac'uire properties of the objects in other classes by way of inheritance. :eusability which is a major factor is provided in object oriented programming which adds features to a class without modifying it. @ew class can be obtained from a class which is already present. 13) Explain about the relationship between object oriented programming and databases? Object oriented programming and relational database programming are almost similar in

software engineering. :&67+ will not store objects directly and thatAs where object oriented programming comes into play. Object relational mapping is one such solution. 11) Explain about a class in OOP? n Object oriented programming usage of class often occurs. " class defines the characteristics of an object and its behaviors. #his defines the nature and functioning of a specified object to which it is assigned. *ode for a class should be encapsulated. 12) Explain the usage of encapsulation? .ncapsulation specifies the different classes which can use the members of an object. #he main goal of encapsulation is to provide an interface to clients which decrease the dependency on those features and parts which are li,ely to change in future. #his facilitates easy changes to the code and features. 1!) Explain about abstraction? "bstraction can also be achieved through composition. t solves a comple0 problem by defining only those classes which are relevant to the problem and not involving the whole comple0 code into play. 1$) Explain what a method is? " method will affect only a particular object to which it is specified. 7ethods are verbs meaning they define actions which a particular object will perform. t also defines various other characteristics of a particular object. 1() ame the different &reational patterns in OO design? #here are three patterns of design out of which *reational patterns play an important role the various patterns described underneath this are> 1) 5actory pattern 2) +ingle ton pattern !) %rototype pattern $) "bstract factory pattern () 6uilder pattern 1)) Explain about realistic modeling? "s we live in a world of objects, it logically follows that the object oriented approach models the real world accurately. #he object oriented approach allows you to identify entities as objects having attributes and behavior. 1-) Explain about the analysis phase? #he anlaysis or the object oriented analysis phase considers the system as a solution to a problem in its environment or domain. &eveloper concentrates on obtaining as much information as possible about the problem. *ritical re'uirements needs to be identified.