CALL - Calling a Method in ABAP Objects ????????

Administrator CALL - Calling a Method in ABAP Objects Variants: Static Variants 1a. CALL METHOD meth [additions].

?????

1b. [CALL METHOD] meth( [additions] ). 2. [CALL METHOD] meth( ). 3. [CALL METHOD] meth( f ). 4. [CALL METHOD] meth( p1 = f1 ... pn = fn ). Dynamic Variants 5a. CALL METHOD ref->(f) [additions].

5b. CALL METHOD class=>(f) [additions]. 5c. CALL METHOD (c)=>meth [additions]. 5d. CALL METHOD (c)=>(f) [additions].

5e. CALL METHOD [ME->](f) [additions]. Effect Call a method meth within ABAP objects. Methods belong to the components of classes. They are accessed either statically using variants 1 through 4 or dynamically using variant 5. Dynamic access to me thods is called Dynamic Invoke. Dynamic access via class references allows you t o call all methods of an object, irrespective of the type of reference variables . The interface of a method is completely defined when the method is declared usin g the METHODS or CLASS-METHODS statement. The additions of the statement CALL ME THOD pass actual parameters to this interface, or accept actual parameters from it. Variant 1a CALL METHOD meth Variant 1b [additions].

[CALL METHOD] meth( [additions] ).

Extras: 1. ... EXPORTING p1 = f1 2. ... IMPORTING p1 = f1 ... pn = fn ... pn = fn

3. ... CHANGING

p1 = f1

... pn = fn

4. ... RECEIVING p = f 5. ... EXCEPTIONS except1 = rc1 ... exceptn = rcn Effect Static Method Call Additions 1 through 5 are used to pass parameters statically. They can also be u sed for static method calls. If no additions are used, the method meth is called without parameter passing and without exception handling. For variant 1a, you must specify the statement CALL METHOD. For variant 1b, wher e the additions are specified in brackets, you can omit the statment CALL METHOD . Variants 2 through 4 are short forms of variant 1b. As before, methods can be called as operands in expressions if they meet certain requirements (see note be low). Addition 1 ... EXPORTING p1 = f1 Effect ... pn = fn

With the EXPORTING addition, the caller must pass type-suitable actual parameter s f1 ... fn to all IMPORTING parameters p1 ... pn of a statically called method. These parameters must not be declared as optional. Example CLASS C1 DEFINITION. PUBLIC SECTION. METHODS M1 IMPORTING P1 TYPE I DEFAULT 5 P2 TYPE C OPTIONAL P3 TYPE D. ENDCLASS. DATA: F TYPE D, O1 TYPE REF TO C1. CREATE OBJECT O1. CALL METHOD O1->M1 EXPORTING P3 = F. CLASS C1 IMPLEMENTATION. METHOD M1. ... ENDMETHOD. ENDCLASS. The method M1 is called using variant 1a. Addition 2 ... IMPORTING p1 = f1 Effect ... pn = fn

Using the optional IMPORTING addition, the caller can copy the EXPORTING paramet ers p1 ... pn of a method into type-suitable actual parameters f1 ... fn. Example

CLASS C1 DEFINITION. PUBLIC SECTION. METHODS M1 EXPORTING P1 TYPE I P2 TYPE C P3 TYPE D. ENDCLASS. DATA: F TYPE D, O1 TYPE REF TO C1. CREATE OBJECT O1. O1->M1( IMPORTING P3 = F ). CLASS C1 IMPLEMENTATION. METHOD M1. ... ENDMETHOD. ENDCLASS. You call the method M1 using variant 1b, while omitting the statement CALL METHO D. Addition 3 ... CHANGING p1 = f1 Effect ... pn = fn

Using the CHANGING addition, the caller must pass type-suitable actual parameter s f1 ... fn to all CHANGING parameters p1 ... pn of a statically called method. These parameters are not declared as optional. As soon as the method is complete , the caller automatically copies the CHANGING parameters into the actual parame ters. Example CLASS C1 DEFINITION. PUBLIC SECTION. METHODS M1 CHANGING P1 TYPE I OPTIONAL P2 TYPE C P3 TYPE D DEFAULT SY-DATUM. ENDCLASS. DATA: F TYPE C, O1 TYPE REF TO C1. CREATE OBJECT O1. CALL METHOD O1->M1 CHANGING P2 = F. CLASS C1 IMPLEMENTATION. METHOD M1. ... ENDMETHOD. ENDCLASS. Methode M1 is called using variant 1a. Addition 4

... RECEIVING p = f Effect Using the optional RECEIVING addition, the caller can copy the return value p of a method meth into a type-suitable actual parameter f. The formal parameter is transferred to the actual parameter in the same way as with an assignment (MOVE) . You must be able to convert the data type of the formalparameter into the data type of the actual parameter. Example CLASS C1 DEFINITION. PUBLIC SECTION. METHODS M1 RETURNING VALUE(R) TYPE I. ENDCLASS. DATA: F TYPE I, O1 TYPE REF TO C1. CREATE OBJECT O1. O1->M1( RECEIVING R = F ). CLASS C1 IMPLEMENTATION. METHOD M1. ... ENDMETHOD. ENDCLASS. You call method M1 using variant 1b, while omitting the CALL METHOD statement. Addition 5 ... EXCEPTIONS except1 = rc1 ... exceptn = rcn Effect Using the optional EXCEPTIONS addition, the caller can handle exceptional situat ions in a method meth. Exceptions are triggered by the statements ,RAISE except, and MESSAGE RAISING in the method. The caller handles an exception except by including it in the EXCEPTIONS list an d by thus creating a link with a return value rc. If the exception is triggered, the system terminates method processing, returns to the caller, and there assig ns the return value rc to the system variable SY-SUBRC. For output parameters of the method that are defined for value passing (EXPORTIN G, CHANGING and RETURNING parameters), no values are passed to the actual parame ters when an exception occurs. For output parameters defined for reference passi ng (default setting), the formal parameters and actual parameters have the same value at any one time. If the caller does not handle an exception triggered by RAISE except, the curren t program terminates. If the caller does not handle an exception triggered by MESSAGE RAISING, the spe cified message is sent, and the system continues processing in accordance with t he message type specified. Notes

As with function modules, you can catch the exception OTHERS predefined by t he system to handle various user-defined exceptions simultaneously. Specifying t he exception ERROR_MESSAGE is, however, not supported for method calls. Note that, as of release 6.10, there are class-based exceptions that are cau ght with TRY ... CATCH ... ENDTRY, and replace the exceptions caught previously using EXCEPTIONS. Example CLASS C1 DEFINITION. PUBLIC SECTION. METHODS M1 EXCEPTIONS EX1 EX2. ENDCLASS. DATA O1 TYPE REF TO C1. CREATE OBJECT O1. O1->M1( EXCEPTIONS EX1 = 10 EX2 = 20 ). CASE SY-SUBRC. WHEN 10. ... WHEN 20. ... ENDCASE. CLASS C1 IMPLEMENTATION. METHOD M1. ... RAISE EX1. ... MESSAGE E012(AT) RAISING EX2. ... ENDMETHOD. ENDCLASS. The method M1 is called using variant 1b, while omitting the statement CALL METH OD. Variant 2 [CALL METHOD] meth( ). Effect This short form of variant 1b can be used for static method call if the method m eth does not have any, or only optional, input parameters (IMPORTING-or CHANGING parameters). No values are passed. Possible EXPORTING or RETURNING parameters a re not accepted after completion of the method. Example See example for variant 4. Variant 3

[CALL METHOD] meth( f ). Effect This short form of variant 1b can be used for static method call in the followin g cases: If the method meth has only one single non-optional input parameter (IMPORTI NG parameter), the system passes the actual parameter f with this variant of the method call to the non-optional input parameter. If the method meth only has optional input parameters, of which one is decla red as a preferred parameter using the addition PREFERRED PARAMETER, the actual parameter f can be passed to the preferred parameter using this variant of the m ethod call. However, this method must not have any other interface parameters (EXPORTING, CH ANGING, or RETURNING parameters). Example See example for variant 4. Variant 4 [CALL METHOD] meth( p1 = f1 ... pn = fn ). Effect This short form of variant 1b can be used for static method call if the method h as several input parameters (IMPORTING parameters), whereby the actual parameter s f1 ... fn are passed. The method must only have optional CHANGING parameters t hat are not filled during this call. Possible EXPORTING or RETURNING parameters are not accepted after completion of the method. Example class C1 definition. public section. methods: M0 importing exporting changing M1 importing M2 importing endclass. class C1 implementation. method M0. ... endmethod. method M1. ... endmethod. method M2. ... endmethod.

P1 type I optional P2 type I P3 type I optional, P1 type I, P1 type I P2 type I returning VALUE(P3) type I.

endclass. data: O1 type ref to C1, NUM1 type I, NUM2 type I. start-of-selection. create object O1. O1->M0( ). O1->M1( NUM1 ). O1->M2( P1 = NUM1 P2 = NUM2 ). This example shows short forms of variant 1b. Note If a method has an arbitrary number of IMPORTING parameters and a RETURNING para meter, it is a functional method, and then it can be called by CALL METHOD as we ll as by the following expressions: No IMPORTING parameters: meth( ) A non-optional IMPORTING parameter or several optional IMPORTING parameters with a preferred parameter: meth( f1 ) n IMPORTING parameters: meth( p1 = f1 ... pn = fn ) This notation style is currently possible For the source field of the MOVE statement. In arithmetic expressions of the COMPUTE statement. In logical expressions. In the CASE statement of the CASE control structure. In the WHEN statement of the CASE control structure. In the WHERE condition of the LOOP AT statement. The functional method is entered instead of an operand. When the statement is ex ecuted, the system calls the method and the returned RETURNING parameter is used as an operand. Variant 5a CALL METHOD ref->(f) Variant 5b [additions].

CALL METHOD class=>(f) [additions]. Variant 5c CALL METHOD (c)=>meth [additions]. Variant 5d

CALL METHOD (c)=>(f) Variant 5e

[additions].

CALL METHOD [ME->](f) [additions]. Extras: 1. ... PARAMETER-TABLE itab 2. ... EXCEPTION-TABLE itab Effect Dynamic Method Call Call The field f must contain the name of the called method at runtime. The object of an instance method is determined, as in the case of the static method call, via a reference variable. You can specify the class of a static method statically v ia class or dynamically as the content of the field c. Variant 5e is only possib le for methods in your own class. Additions 1 and 2 are used for dynamic also use additions 1 through 5 of the interface of the called method must be method call, the statement CALL METHOD Addition 1 ... PARAMETER-TABLE itab Effect This addition fills the interface of a dynamically called method with actual par ameters. The addition PARAMETER-TABLE excludes simultaneous use of the static ad ditions 1 thorugh 4 of variant 1. The parameter table itab must be a hashed table of the table type ABAP_PARMBIND_ TAB or of the line type ABAP_PARMBIND. These types are defined in the ABAP type group in the ABAP dictionary. The table has three columns: NAME for the name of the formal parameter KIND for the type of parameter passing VALUE of the type REF TO DATA for the value of the actual parameter The column NAME is the unique table key. Exactly one line of the internal table must be filled for each non-optional parameter, and one line CAN be filled for e ach optional parameter. The type of parameter passing is defined for each formal parameter in the declar ation of the called method. The content of the column KIND can, therefore, be in itial. If the type of parameter passing is to be checked at runtime, you can ass ign one of the following constants from the global class CL_ABAP_OBJECTDESCR to the column KIND. CL_ABAP_OBJECTDESCR=>EXPORTING for EXPORTING parameters CL_ABAP_OBJECTDESCR=>IMPORTING fr IMPORTING parameters CL_ABAP_OBJECTDESCR=>CHANGING fr CHANGING parameters CL_ABAP_OBJECTDESCR=>RECEIVING fr RECEIVING parameters parameter passing. Alternatively, you can static method call, but in this case the statically known. If you use the dynamic must not be omitted.

The descriptions depend on the caller's view. If the specified and actual parame ter types do not match each other, the system generates the exception CX_SY_DYN_ CALL_ILLEGAL_TYPE, which can be handled. As before, the entries in the column KI ND can serve as an additional key, for example, to edit all the imported values after the method call. For the value of the actual parameter, the reference VALUE of the table line mus t point to a data object that contains the required value. For this purpose, you can use the command GET REFERENCEOF f INTO g. Example CLASS cl_abap_objectdescr DEFINITION LOAD . CLASS c1 DEFINITION. PUBLIC SECTION. METHODS m1 IMPORTING p1 TYPE i. ENDCLASS. CLASS c1 IMPLEMENTATION. METHOD m1. WRITE p1. ENDMETHOD. ENDCLASS. DATA r TYPE REF TO object. DATA f(3) TYPE c VALUE 'M1'. DATA number TYPE i VALUE 5. DATA: ptab TYPE abap_parmbind_tab, ptab_line LIKE LINE OF ptab. START-OF-SELECTION. ptab_line-name = 'P1'. ptab_line-kind = CL_ABAP_OBJECTDESCR=>EXPORTING. GET REFERENCE OF number INTO ptab_line-value. INSERT ptab_line INTO TABLE ptab. IF sy-subrc ne 0. EXIT. ENDIF. CREATE OBJECT r TYPE c1. CALL METHOD r->(f) EXPORTING p1 = number. CALL METHOD r->(f) PARAMETER-TABLE ptab. Method m1 of the class c1 is called twice dynamically, whereby the parameter pas sing takes place once statically and once dynamically. The used reference variab le is set for the type with reference to the general class OBJECT. Addition 2 ... EXCEPTION-TABLE itab Effect With this addition, the exceptions of a dynamically called method are handled dy namically. The addition EXCEPTION-TABLE excludes simultaneous usage of the stati

c addition 5, variant 1. The exception table itab must be a hashed table of the table type ABAP_EXCPBIND_ TAB or of the line type ABAP_EXCPBIND. These types are defined in the ABAP type group in the ABAP dictionary. The table has two columns: NAME for the name of the exception VALUE of type I for the SY-SUBRC value to be assigned The column NAME is the unique table key. For each exception, exactly one line of the internal table can be filled. Here the numeric value is assigned to the com ponent VALUE, which should be in SY-SUBRC after the exception has been triggered . Example CLASS cl_abap_objectdescr DEFINITION LOAD. CLASS c1 DEFINITION. PUBLIC SECTION. METHODS m1 EXCEPTIONS exc. ENDCLASS. CLASS c1 IMPLEMENTATION. METHOD m1. RAISE exc. ENDMETHOD. ENDCLASS. DATA r TYPE REF TO object. DATA f(3) TYPE c VALUE 'M1'. DATA: etab TYPE abap_excpbind_tab, etab_line LIKE LINE OF etab. START-OF-SELECTION. etab_line-name = 'EXC'. etab_line-value = 4. INSERT etab_line INTO TABLE etab. IF sy-subrc ne 0. EXIT. ENDIF. CREATE OBJECT r TYPE c1. CALL METHOD r->(f) EXCEPTIONS exc = 4. WRITE sy-subrc. CALL METHOD r->(f) EXCEPTION-TABLE etab. WRITE sy-subrc. The method m1 of the class c1 is called twice dynamically, whereby the exception handling takes place once statically and once dynamically. The user reference v ariable is set to the type with reference to the general class OBJECT. Exceptions Catchable Exceptions CX_SY_DYN_CALL_EXCP_NOT_FOUND

Cause: Exception does not exist Runtime Error: DYN_CALL_METH_EXCP_NOT_FOUND (catchable) CX_SY_DYN_CALL_ILLEGAL_CLASS Cause: The specified class is abstract. Runtime Error: DYN_CALL_METH_CLASS_ABSTRACT (catchable) Cause: The specified class does not exist Runtime Error: DYN_CALL_METH_CLASS_NOT_FOUND (catchable) CX_SY_DYN_CALL_ILLEGAL_METHOD Cause: The method cannot be accessed. Runtime Error: CALL_METHOD_NOT_ACCESSIBLE Cause: The called method is not yet implemented. Runtime Error: CALL_METHOD_NOT_IMPLEMENTED Cause: Call of static constructor Runtime Error: DYN_CALL_METH_CLASSCONSTRUCTOR (catchable) Cause: Call of instance constructor Runtime Error: DYN_CALL_METH_CONSTRUCTOR (catchable) Cause: Method does not exist Runtime Error: DYN_CALL_METH_NOT_FOUND (catchable) Cause: Method is not static Runtime Error: DYN_CALL_METH_NO_CLASS_METHOD (catchable) Cause: Call of a method that is not visible Runtime Error: DYN_CALL_METH_PRIVATE (catchable) Cause: Call of a method that is not visible Runtime Error: DYN_CALL_METH_PROTECTED (catchable) CX_SY_DYN_CALL_ILLEGAL_TYPE Cause: Type conflict calling the method. Runtime Error: CALL_METHOD_CONFLICT_GEN_TYPE Cause: Type conflict calling the method. Runtime Error: CALL_METHOD_CONFLICT_TAB_TYPE Cause: Type conflict calling the method. Runtime Error: CALL_METHOD_CONFLICT_TYPE Cause: Incorrect type of a parameter Runtime Error: DYN_CALL_METH_PARAM_KIND (catchable) Cause: Actual parameter cannot be filled Runtime Error: DYN_CALL_METH_PARAM_LITL_MOVE (catchable) Cause: Incorrect table type of a parameter Runtime Error: DYN_CALL_METH_PARAM_TAB_TYPE (catchable) Cause: Incorrect type of a parameter Runtime Error: DYN_CALL_METH_PARAM_TYPE (catchable) CX_SY_DYN_CALL_PARAM_MISSING Cause: Missing actual parameter Runtime Error: DYN_CALL_METH_PARAM_MISSING (catchable) Cause: Parameter reference is empty Runtime Error: DYN_CALL_METH_PARREF_INITIAL (catchable) CX_SY_DYN_CALL_PARAM_NOT_FOUND Cause: Incorrect name of a parameter Runtime Error: DYN_CALL_METH_PARAM_NOT_FOUND (catchable) CX_SY_REF_IS_INITIAL

Cause: Reference variable is empty Runtime Error: DYN_CALL_METH_REF_IS_INITIAL (catchable) Non-Catchable Exceptions Cause: Non-allowed parameter during dynamic method call. Relevant for instance constructors during dynamic instantiation. Runtime Error: CALL_METHOD_PARMS_ILLEGAL Related ALIASES Declaration of an alias name CALL METHOD Call of a method CLASS ... ENDCLASS Definition of a class CLASS-DATA Declaration of a static attribute CLASS-EVENTS Declaration of a static event CLASS-METHODS Declaration of a static method CREATE OBJECT Creation of an object EVENTS Declaration of an instance event INTERFACE ... ENDINTERFACE Definition of an interface INTERFACES Including an interface METHOD ... ENDMETHOD Definition of a method METHODS Declaration of an Instance method PRIVATE SECTION Start of private visibility section PROTECTED SECTION Start of a protected visibility section PUBLIC SECTION Start of the public visibility section RAISE EVENT Triggering an event SET HANDLER Registering an event

-----------------------------------------------------------------------------------------------------------------------------------------------------------new ------------------------------------------------------------------------------------------------------------------------------------------------------------

Object References References have been introduced in ABAP in conjunction with ABAP Objects. Distin ction is made between data references and object references. Object references a re used as pointers to objects. Object references (the values of reference varia bles) are the only way to access the components of an object in an ABAP program. You can use references to access attributes and methods, but not events. Reference Variables Reference variables contain references. A reference variable f is either initial or contains a reference to an existing object. In the latter case, the logical expression f IS BOUND is true. A reference variable that points to an object con tains the 'address' of the object. Objects and their components can only be addr essed through references. In ABAP, reference variables are treated like other data objects with an element

ary data type. This means that a reference variable need not be a standalone fie ld, but can also be a component of complex data objects, for example, structures and internal tables. Data Types for References ABAP contains a special data type for references, comparable to the special data types for structures or internal tables. The full data type is defined when you declare the variable in the ABAP program. It determines how the program handles the value of the variable (the object reference itself). There are two kinds of references: Class Reference You define class references in full using the addition TYPE REF TO class of the TYPES or DATA statement, where class is a class that is recognized in the de claration part of the program. Reference variables of this type are called class reference variables, or just c lass references. A class reference cref allows users to use the form cref->comp to access all of the visible components comp of the object to which the object reference points, that is, usually all public components of the class. Interface References You define interface references in full using the TYPE REF TO intf addition of the TYPES or DATA statement, where intf is an interface that has already been declared in the program. References of this kind are called interface reference variables, or interface references. With an interface reference iref, you can use the form iref->icomp to access all of the visible interface components icomp of the object to which the refere nce points. Interface components are those components of an object that are decl ared by implementing the interface in the class. As well as in declarations, you can use the TYPE REF TO ... addition in all othe r statements in which type specifications are possible, for example, to specify the types of interface parameters in procedures. Special References Two specific references exist in a class, the self-reference ME and the pseu do reference SUPER. The self-reference is used to address an object's own components explicitly. In the instance methods of a class, ME is a predefined local reference variable with the type of its class whose content points to its own instance. It can be specified to address its own component but does not have to be specified. It can also be assigned to other reference variables or passed to methods. The pseudo reference SUPER is used to call the hidden method in a redefined instance method in connection with inheritance. The pseudo reference is not a ge nuine reference because an instance of a subclass cannot have an associated supe rclass instance, that is, no corresponding reference variable. The pseudo refere nce SUPER is the syntactical expression for a method call in a superclass. Initializing Reference Variables Like other variables, reference variables are initialized using the statement CL EAR. The initial value of a reference variable is a reference which does not poi nt to any object.

Assigning References - Narrowing Cast You can assign references between reference variables using the MOVE statement. This means that the references in several references variables can point to the same object (sharing). If you make assignments between reference variables, the dynamic type of the source variable must be compatible with the static type of t he target variable. The dynamic type is the class of the object to which the ref erence in a reference variable points. The static type is the type (class or int erface) with which the reference variable has been typed. The static type of the target variable must always be more generic than the dynamic type of the source variable. The syntax check in the program can only compare the static type of the source v ariable with the static type of the target variable. When you assign reference v ariables using the MOVE statement or the assignment operator (=), the system per forms this comparison. You can only make assignments that fulfill the above requ irements for static types (narrowing cast). The same applies when passing parame ters to procedures. Assignments are always possible if the static type of the ta rget variable can address the same number of components as the static type of th e source variable or fewer components: If cref1 and cref2 are class references, and iref1 and iref2 are interface refer ences, the following assignments can be checked statically: cref1 = cref2 Both class references must refer to the same class, or the class of cref1 is a superclass of the class of cref2. The class of cref1 can always be OBJECT bec ause Object is the superclass for all classes in ABAP Objects. iref1 = iref2 Both interface references must refer to the same interface, or the interface of iref2 must be a nested interface, including the interface of iref1 as a comp onent. iref1 = cref1 The class of class reference cref1 or one of its superclasses must implement the interface of interface reference iref1. The implementation can be performed directly or using a nested interface, which includes the interface of iref1 as a component. cref1 = iref1 The class of cref1 must be OBJECT, that is, the reference variable cref1 mus t have the type REF TO OBJECT. OBJECT is a predefined empty class and the root node for all inheritance trees i n ABAP Objects. This class has no components and has a similar function for refe rence variables as the data type ANY has for normal variables. Reference variabl es with the type OBJECT can be used as containers for passing references. They c annot be used for static access to objects; however, dynamic access is possible. Assigning References - Widening Cast If a static type check is not possible, or whenever you want the type check to t ake place at runtime, use the MOVE ... ?TO statement or the casting operator (?= ). The casting operator replaces the assignment operator (=). When you use eithe r of these options, there is no static type check. Instead, the system checks at runtime whether the object reference of the source variable points to an object

to which the object reference in the target variable may also point (widening c ast). The dynamic type of the source variable is compared with the static type o f the target variable. The system assigns the reference if this is possible, oth erwise, it generates the exception CX_SY_MOVE_CAST_ERROR which can be handled. The syntax requires you to use a widening cast in all cases that are not listed above under static type checks. For example: cref1 ?= iref1 Assigning an interface refernce to a class reference. For the assignment to be successful, the object to which iref1 points must belong to the same class as the type of the class variable cref1 or to an apppropriate subclass. Object References as Actual Parameters You can pass object references as actual parameters to procedures (methods, func tion modules, and subroutines) by specifying object reference variables. As far as typed formal parameters are concerned, note that you may only pass actual par ameters of exactly the same type if the formal parameter can be changed in the p rocedure. This applies also to EXPORTING and CHANGING parameters of function mod ules and methods, parameters in subroutines passed by reference and CHANGING par ameters in subroutines passed by value. Passing actual parameters to formal parameters which is equivalent to a narrowin g cast, such as passing a class reference variable to a formal parameter which i s typed with reference to an interface of the class or one of its superclasses, is not possible if the parameter can be changed in the procedure. The reason is that a reference could be assigned to the actual parameter in the procedure which is incompatible with its static type, such as a reference to any other class that implements the same interface or a referene to a subclass in a nother node of the inheritance tree. Assigning Object References to Field Symbols When you assign object references to typed field symbols, the same applies as wh en you pass a reference to typed formal parameters: The types must be identical. Otherwise, incompatibilities between dynamic and static types may occur. For ex ample, if you assign two class reference variables of different classes implemen ting the same interface one after the other to the same field symbol, an inconsi stent state results.