Wood J. Object-Oriented Programming with ABAP Objects
Подождите немного. Документ загружается.
4 | Object Initialization and Cleanup
constructor IMPORTING im_account_no
TYPE string.
get_balance RETURNING VALUE(rebalance)
TYPE bapicurr_d.
deposit IMPORTING im_amount
TYPE bapicurr_d.
withdrawal IMPORTING im_amount
TYPE bapicurr_d
RETURNING VALUE(re_result)
TYPE abap_bool.
PRIVATE SECTION.
DATA: account_no TYPE string.
balance TYPE bapicurr_d.
ENDCLASS.
CLASS lcl_account IMPLEMENTATION.
METHOO constructor.
* Query database tables to retrieve account details:
* SELECT FROM ...
* WHERE account_no - im_account_no.
ENDMETHOD.
METHOO get_balance.
re_balance - balance.
ENDMETHOD.
METHOO deposit.
balance - balance + im_amount.
ENDMETHOD.
METHOO withdrawal.
IF im_amount LE balance.
balance - balance - im_amount.
re_result - abap_true.
ELSE.
"Exception handling code...
ENOIF.
ENDMETHOD.
ENDCLASS.
Listing 4.3 Initializing an Account Class Using a Constructor
114
Controlling Object Initialization with Constructors
As you look at the code in Listing 4.3. notice how the addition of method con
structor has effectively put a lock on the front door of
class
lcl_account. Clients
requesting objects in reference to this class must provide a valid account number,
so we don't have to woriy about which account we are working on inside the var-
ious methods in the public interface.
For example, notice how methods deposit and withdraw did not contain any
logic to determine which account to post the transactions against. Here, this is not
needed because we have guaranteed proper initialization of the object and
restricted access to the sensitive attributes of the class. The object lifecycle begins
by pulling up the latest account details from the database and can only be further
influenced through public methods containing business logic to ensure that users
do not compromise the integrity of the object in any way.
Most of the time, whenever we talk about constructors, we arc typically talking
about instance constructors that are used to initialize an instance of
an
object that
is being created. However, it is also possible to supply a class constructor for a
class. Class constructors provide a mechanism for initializing the class (or static)
attributes of a class. A class constructor is called implicitly by the system before
any accesses are made to the class inside your program. Class constructors are
defined using the syntax shown in Listing 4.4.
CLASS-METHODS class.constructor.
Listing 4.4 Syntax for Defining a Class Constructor
As you can see in Listing 4.4, you cannot specify any parameters for a class con-
structor because it is being called implicitly by the system. It is also worth men-
tioning here that you cannot access instance components within the class con-
structor because no instances of the class exist when it is being called. Of course,
it is possible to instantiate an object of the class at this point. Here, you simply
access the instance components of the object through a local object reference
variable just as you would in any normal method implementation.
Class constructors can be created for global classes by clicking the CLASS CON-
STRUCTOR button on the Class Editor screen (see Figure 4.5). The report program
ZC0UNTER_DEM0 shown in Listing 4.5 demonstrates how class constructors can be
used to initialize class attributes.
115
4 | Object Initialization and Cleanup
Class Builder: Change Class ZCL_ACCOUNT
l ©0S© i @I)DSHI Id conttoKttfji
IZOJUXOIMT Class interface
implemented I A<»v» (revised)
|HJ...,..T UL2K23 \c
LL
-
LIV
K IP. IF! F BIR
CONSTRUCTOR
|L 0-^E.I |v«i |M |u«scneoon
Inst»ncPut>1i$$ CONSTRUCTOR
Figure 4.5 Creating Class Constructors for Global Classes
REPORT zcounter_demo.
CLASS lcl.counter DEFINITION.
PUBLIC SECTION.
CLASS-METHODS: class_constructor.
METHODS: increment.
get.count RETURNING VALUE(re.count)
TYPE i.
PRIVATE SECTION.
CLASS-OATA: count TYPE i.
ENOCLASS.
CLASS lcl.counter IMPLEMENTATION.
METHOD c!ass_constructor.
count - 10.
ENDMETHOD.
METHOD increment.
count - count + 5.
ENDMETHOD.
METHOD get.count.
re_count - count.
ENDMETHOD.
ENDCLASS.
DATA: 1r_counterl TYPE REF TO lcl.counter.
lr_counter2 TYPE REF TO lcl_counter.
1v_count TYPE i.
116
Taking Control of the Instantiation Process
START-OF-SELECT ION.
CREATE OBJECT 1r_counterl.
lv_count - 1r_counterl->get_count( ).
WRITE: / 1v_count.
DO 10 TIMES.
1r_counterl->increment( ).
ENDDO.
lv_count - 1r_counterl->get_count( ).
WRITE: / 1v_count.
CREATE OBJECT 1r_counter2.
1r_counter2->increment( ).
lv_count - 1r_counter2->get_count( ).
WRITE: / 1v_count.
Listing 4.5 An Example Program Using a Class Constructor
If you run the ZCOUNTER_DEMO report, you will see that the class constructor has
taken care of pre-initializing the count class attribute to the value 10 prior to the
creation of the
1
r_counterl object. After the
1
r_counterl object is initialized, the
instance method increment is called 10 times, incrementing the value of the
counter by 5 each time. After this loop is completed, the value of the count
attribute will be 60. Next, another object named l r_counter2 is created. Here, the
class constructor is not called again, so the count attribute is not affected. Conse-
quently, whenever the call is made to increment for the lr_counter2 object,
count is incremented to 65.
As you can see in the example, class constructors provide a handy way to initialize
class attributes prior to the creation of object instances. Often, class constructors
are used to initialize common resources that arc used inside instance construc-
tors.
4.3 Taking Control of the Instantiation Process
Until now, it has been possible to create instances of the classes we have devel-
oped anywhere that the class itself is visible using the CREATE OBJECT statement.
This is the default behavior for local and global classes. However, in certain cases,
it is useful to take control of the instantiation of objects within the class itself.
117
4 | Object Initialization and Cleanup
This kind of behavior can be specified using the CREATE addition of the CLASS
DEFINITION statement. This syntax is depicted in Listing 4.6.
CLASS lcl_some_class DEFINITION
CREATE {PUBLIC | PROTECTED | PRIVATE!.
ENDCLASS.
Listing 4.6 Specifying the Instantiation Context of a Class
You can set the instantiation context for global classes on the PROPERTIES tab of the
Class Editor (see Figure 4.6).
Class interface
CL_A8AP_RAH00I1 .INT impiemen
A interfaces U Friends L Attributes U Methods ^
Undo inherltanc Change inherit
Description
Private 3
Private
Protected
Public
Abstract
Released internally
FlFced point anthmeat R Unicode checks actwe
r Shared Memory-Enabled
Figure 4.6 Setting the Instantiation Context for Global Classes
Table 4.1 describes each of the possible instantiation contexts that can be defined
for classes.
Instantiation Context Visibility
PUBLIC
These classes can be instantiated anywhere that the
class itself is visible without restrictions.
PROTECTED
These classes can only be instantiated inside methods
of the class itself and its subclasses.
PRIVATE
These classes can only be instantiated inside methods
of the class itself.
Table 4.1 Instantiation Contexts for Classes
118
Instantiation
F Final
General Data
Taking Control of the Instantiation Process
Perhaps the best way to illustrate the utility of controlled instantiation is to look
at how it might be used in a practical example. Let's imagine that you want to
build a class library that can be used to process XML documents. To maximize the
usefulness of your XMLDocument class, you want to be able to load XML documents
from a number of different types of data sources. For instance, you might want to
build the XML document using a file, a byte stream, a tree-like data structure, and
so on.
In many object-oriented languages, this problem can be solved by overloading the
constructor method to support different method signatures. Here, each over-
loaded constructor method has the same name but a different set of parameters.
Unfortunately, this is not a feature supported in ABAP Objects. One common
workaround for this limitation is to create multiple optional parameters in the
constructor's method signature and try to figure out which scenarioyou are deal-
ing with inside the constructor's implementation using conditional logic. Listing
4.7 shows an IF statement that uses the IS SUPPLIED option to determine if
parameter lm_paraml was supplied to the method during the method call.
IF im_paraml IS SUPPLIEO.
ENDIF.
Listing 4.7 Determining if Parameters Are Passed in a Method Call
The problem with this technique is that the signature of the constructor method
becomes quite large and difficult to work with. The logic in the constructor code
also becomes obscured by all of the various input permutations.
As you have seen, our typical approach for dealing with complexity is to figure
out a way to encapsulate (or hide) it. In this case, we want to encapsulate the
instantiation process to make it more straightforward and intuitive. One way to
encapsulate this process is to configure the XML document class to have a pro-
tected/private instantiation context. This implies that users will no longer have
the ability to directly instantiate XML document objects. Instead, they must work
with public creational class methods that arc customized to build XML documents
using various types of inputs (see Listing 4.8). These methods behave like a con-
structor, taking control of the initialization process. This is important because the
primary goal here is to simplify the initialization process so that a single construc-
tor is not responsible for supporting all of the various initialization variants that
we want to provide.
119
Object Initialization and Cleanup
CLASS lcl_xm1_document DEFINITION
CREATE PRIVATE.
PUBLIC SECTION.
CLASS-METHODS:
create_from_scratch RETURNING VALUE(re_xml_doc)
TYPE REF TO lc1_xml_document
create_from_file IMPORTING im_filename
TYPE string
RETURNING VALUE(re_xml_doc)
TYPE REF TO lcl_xml_document
create_from_stream IMPORTING im_stream
TYPE xstring
RETURNING VALUE(re_xml_doc)
TYPE REF TO lcl_xml_docunent
"Other Creational Methods...
•Utility Methods...
as.string RETURNING value(re_string)
TYPE string.
PRIVATE SECTION.
METHODS: constructor.
ENDCLASS.
CLASS 1cl_xml_document IMPLEMENTATION.
METHOD constructor.
* Default initialization code goes here...
ENDMETHOD.
METHOD create_from_scratch.
* Use the basic constructor logic to create
* an empty XML document:
CREATE OBJECT re_xml_doc.
ENDMETHOD.
METHOD create_from_file.
* Use the private constructor to build a
* basic XML document:
CREATE OBJECT re_xml_doc.
* Read the given file and load the XML
* document using utility/setter methods:
* OPEN DATASET im_fi1ename...
ENDMETHOD.
120
Garbage Collection
HETHOO create_from_stream.
* Use the private constructor to build a
* basic XHL document:
CREATE OBJECT re_xml_doc.
* Load the byte stream into the XML document:
*
ENDMETHOD.
METHOD as_string.
* re_string - ...
ENDMETHOD.
ENOCLASS.
Listing 4.8 Controlling Instantiation Through Creational Methods
Noticc that each of the creational methods shown in Listing 4.8 use the CREATE
OBJECT statement to create a base XML document object. As stated before, the pri-
vate instantiation context only restricts external users of the class from accessing
the constructor; internal methods are still free to use it. In the case of class
1cl_xml_document the basic initialization logic can still reside inside the private
constructor. The creational methods simply build on this base object to initialize
the XML document using the desired data source.
4.4 Garbage Collection
After you have finished using an object in your program, you need to make sure
that you restore its resources to the system. In some languages, it is the program-
mer's responsibility to make sure that objects are properly destroyed. Fortu-
nately. this is not the case with ABAP Objects because object resources are auto-
matically cleaned up by a special memoiy management feature of the ABAP
runtime environment called th e garbage collector. The garbage collector's job is to
scan through memoiy and delete objects that no longer have any references asso-
ciated with them (i.e., "orphans").
Much of the time, these references are destroyed automatically whenever an
object reference variable goes out of
scope
(i.e., when a subroutine or method ter-
minates). However, if you are done with an object, it is a good idea to explicitly
remove the reference using the CLEAR oref statement (see Figure 4.7).
121
4 | Object Initialization and Cleanup
Some programming languages allow you to create a special lifecycle method
called a destructor that gets called before an object is destroyed. This method can
be used to manage any internal resources for the object that need to be released
gracefully (e.g.. open file handles, etc.). Regrettably, this method is not used in
ABAP Objects, so it is important to remember to clean up any of these kinds of
internal object resources via an explicit method call before allowing the object to
be destroyed.
4.5 Tuning Performance
The advanced memory management features of the ABAP runtime environment
provide a safe environment for creating and destroying objects. However, it is
122
Tuning Performance
important to remember that these features will not prevent you from making
poor design decisions that consume excessive amounts of memory. In this sec-
tion, we will provide some basic tips that you can use to avoid these performance
traps.
4.5.1 Design Considerations
Even if you don't anticipate performance problems for a given class, it is always
a good idea to modularize the initialization logic of the class so that you can
implement performance tuning measures later without disturbing core function-
ality, and so on. The following list contains some basic modularization tips that
you should consider when developing your classes:
• Keep the logic inside the constructor method to a minimum by delegating ini-
tialization tasks to modularized private helper methods.
• Provide yourself
a
public reset method that can be used to clear the values of
a class's attributes.
• Tiy to avoid adding too many parameters to the constructor method's inter-
face. Instead, encapsulate the initialization process inside of a series of cre-
ational methods as shown in Section 4.3, Taking Control of the Instantiation
Process.
4.5.2 Lazy Initialization
Sometimes, you may have large composite objects that contain lower-level details
that are not frequently used. For example, let's imagine that you are tasked with
designing a purchasing system. One of the main classes for this system is a Pur
chaseOrder class that contains an internal table attribute of PurchaseOrderltem
objects that also in turn contain a table of ScheduleLine objects. Based on the
functional requirements, you observe that this class is primarily used to query
header level information such as the PO status, partner details, and so on.
In a situation such as this, it can be advantageous to delay the initialization of the
lower-level details until they are needed. Here, once again, you are protected by
encapsulation because you can control access to these lower-level attributes
through getter methods that initialize the attributes on demand whenever they
are first requested. This technique is referred to as lazy initialization. The basic
123