Wood J. Object-Oriented Programming with ABAP Objects
Подождите немного. Документ загружается.
3 | Encapsulation and Implementation Hiding
Figure 3.5 shows a simple sequence diagram that is used to illustrate a cash with-
drawal transaction in an ATM machine. A sequence diagram is essentially a graph
in two dimensions:
• The various objects involved in the interaction are aligned along the horizontal
axis.
• The vertical axis represents time.
Figure 3.5 Sequence Diagram for Withdrawing Cash from an ATM
Sequence diagrams are initiated by a request message from some kind of external
source. In the example in Figure 3.5, the external source is a user interfacing with
the ATM. This initial message is called a found message. In object-oriented terms,
a message is analogous to a method call. Messages are sent to objects (depicted in
104
Summary
the familiar object boxes seen on the object diagrams described in Section 2.6,
UML Tutorial: Object Diagrams). The dashed line protruding from underneath
the object box represents the object's lifeline. In Chapter 11. ABAP Object Ser-
vices. we will examine situations where objects are created and destroyed within
the interaction; for now. we will only consider sequences where all of the objects
exist throughout the entire interaction.
The intersection of
a
message and an object's lifeline is depicted with a thin rect-
angular box called an activation bar. The activation bar shows when an object is
active during the interaction. Objects are activated via messages (i.e., method
calls). Messages can include parameters that help clarify the operation to be per-
formed by the object. However, it is not a good idea to try and fully specify the
method interface in a sequence diagram — that's what a class diagram is for.
Here, we only use parameters for emphasis or clarity. Synchronous method calls
can have a return message that can also have optional parameters.
In some cases, a method might need to call other local helper methods to com-
plete its task. In this case, a self call can be illustrated by drawing a circuitous
arrow to another activation bar that is stacked on top of the current activation
bar. For example, in Figure 3.5, messages dispenseCash and printReceipt are
both represented as self calls on the atm object inside method withdraw.
Sequence diagrams are veiy useful for explaining complex interactions where the
order of operations is difficult to follow. One of the reasons that sequence dia-
grams are so popular is that the notation is veiy intuitive and easy to read. To
maintain this readability, it is important to avoid cluttering a sequence diagram
with too many interactions. In the coming chapters, we will look at other types of
interaction diagrams that can be used to illustrate fine-grained behavior within an
object or more involved interactions that span multiple use cases.
3.7 Summary
In this chapter, you learned about the many advantages of applying encapsulation
and implementation hiding techniques to your class designs. Encapsulating data
and behavior in classes simplifies the way that users work with classes. Hiding the
implementation details of these classes strengthens the design even further, mak-
ing classes much more resistant to data corruption. The combination of these two
design techniques helps you to design intelligent classes that are highly self-suffi-
105
3 | Encapsulation and Implementation Hiding
cient. Such classes are easy to reuse in other contexts because they are loosely
coupled to the outside world.
In the next chapter, we will examine the basic lifecycle of
an
object. Here, we will
also learn about special methods called constructors that can be used to ensure
that object instances are always created in a valid state.
106
Some of the most elusive bugs to detect in a program can be traced back
to missing or invalid variable initializations. This chapter explores how
classes can be enhanced to ensure that objects are properly initialized
prior to their use in programs.
4 Object Initialization and Cleanup
In the previous chapter, you learned how encapsulation and implementation hid-
ing techniques can be used to protect the integrity of
an
object. Such objects pro-
duce consistent and reliable results, freeing developers from constantly worrying
about data correctness issues in their programs. However, all of these measures
are wasted if we fail to properly initialize the object in the first place.
In this chapter, we will investigate how special methods called constructors can be
used to ensure that an object will always be created in a valid state. We will also
examine the overall object lifecycle, paying particular attention to how object
resources arc managed by the automatic mcmoiy management functionality built
into the ABAP runtime environment.
4.1 Creating Objects
One of the primary goals of the object-oriented design process is to identify ways
to delegate responsibilities to objects. This approach transfers complexity from
the main program into objects that are intelligent enough to handle the tasks they
are assigned. To coordinate these efforts, the main program needs to be able to
create and destroy objects on demand. As you can imagine, this dynamic alloca-
tion process can get pretty involved for complex object types. Fortunately, the
ABAP runtime environment takes care of most of the details, making it relatively
painless for developers to create and work with objects in their programs.
Of course, there arc costs associated with creating objects dynamically. To recog-
nize how these costs can affect the performance of your program, it is important
107
4 | Object Initialization and Cleanup
to understand what is going on behind the scenes whenever you request the cre-
ation of an object using the CREATE OBJECT statement.
To put all of this in perspective, let's consider an example of a report program
running inside a SAP GUI window that needs to create an object at runtime. How-
ever, before we start investigating this particular scenario, we first need to under-
stand how memory is organized and used inside of an SAP NetWeaver Applica-
tion Server ABAP (AS ABAP) instance.
Figure 4.1 gives a high level overview of the memory architecture of the AS
ABAP. showing the local memoiy used by the individual work processes along
with the shared memoiy that is used throughout the application server. When-
ever you log on to the SAP system, it creates a user session (or context) inside the
roll buffer area of shared memoiy. This user session keeps track of administrative
items such as your assigned authorizations, and so on. It also keeps track of the
program(s) you are running along with the data objects that are being used by
those programs.
Figure 4.1 8asic Memory Architecture of AS ABAP
Creating Objects
Each SAP GUI window that you open allocates a separate memory area inside the
user session called a main session. Whenever you execute a program in that win-
dow. the system creates yet another memoiy area called an internal session inside
this main session. The internal session manages the data objects of the program
that is running, as well as the data objects of other programs (e.g., function pools,
class pools, etc.) that are being used by that program.
As
you can see in Figure 4.2.
it is possible to have multiple internal sessions inside of a main session. Addi-
tional internal sessions are created whenever a program calls another program,
creating a type of program call stack inside of the main session.
Main Session
Internal Session-
Function
Croups
M.i in
Croups
Program Program
Class Pools
Internal Session 2
Internal Session 1
Figure 4.2 Logical Memory Areas in a Main Session
In an effort to optimize system resources, SAP decided to distribute the load of
executing programs on an application server by multiplexing work processes. The
basic idea here is to share a limited amount of work processes across a large num-
ber of users that are only interacting with the system part of the time. For exam-
ple, you might open up an SAP session, execute a report transaction, and then sit
there reviewing it for a few minutes while sipping a cup of
coffee.
Rather than tie
up a work process while you are sitting idle, the system will simply take a note of
where you are in your program (by storing information in your user session) and
then reassign the work process to another user that has made a request.
The process of assigning and unassigning work processes to a user is generally
described as a roll-in or roll-out. During a roll-in, the user session is loaded from
the roll buffer into the local memory of
a
work process (refer to Figure 4.1). Sim-
ilarly, when a roll-out occurs, information about the state of the currently cxecut-
109
4 | Object Initialization and Cleanup
ing program is copied back into the roll buffer. One of the ways the system
speeds up the roll-in/roll-out process is to keep the user session small by making
use of pointers. Pointers, as the name suggests, are special lightweight variables
that contain a memoiy address that is used to point to data objects that are stored
elsewhere. In the case of the AS ABAP, pointers typically point to data objects
stored in the extended memoiy area of the shared memoiy.
Now thatyou have a better appreciation for how the various memory areas of an
AS ABAP instance are used, let's get back to our report program example. Inside
of
a
processing block in the report program, you would request the creation of an
object using the CREATE OBJECT statement as shown in Listing 4.1.
DATA: oref TYPE REF TO lcl_some_class.
CREATE OBJECT oref.
Listing 4.1 Creating an Object Using the CREATE 08JECT Statement
At this point, the ABAP runtime environment uses the definition information
from class lcl_some_class to determine how much memory it needs to allocate
for an instance of this class type. After it knows how much memory it needs, the
runtime environment then needs to scan through the extended memoiy area to
find a chunk of memory large enough to store the object and its data. It also needs
to allocate some additional memory to store a header data structure that is used to
keep track of various administrative details about the object. After the memory is
allocated, the address of the header structure is returned to the object reference
variable oref (see Figure 4.3).
The primary consequence of this approach for dynamically generating objects is
the additional time required to allocate the proper amount of memory for an
object. As multiple programs create and destroy objects, the extended memory
area can start to become fragmented, making it difficult to locate a contiguous
chunk of memoiy large enough to hold an object. Skeptics sometimes point to
these performance costs as a reason for not using objects in their programs, claim-
ing that they can't afford the additional overhead at runtime. However, if you
look carefully at your existing programs, you will likely find thatyou are already
using many types of dynamic data objects
1
.
1 For an excellent description of dynamic data objects, check out Horst Keller's blog entitled ABAP
Geek 12 — The Deep (https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2016).
110
Controlling Object Initialization with Constructors
Figure 4-3 Memory Allocation for Objects
For example, internal tables are dynamic data objects that require additional
memory to be dynamically allocated as additional rows are appended to them.
Most design decisions involve some kind of trade-off, and in the case of objects,
you might have to sacrifice a little bit of performance to realize the many benefits
of Object-Oriented Programming (OOP). Fortunately. SAP has optimized the per-
formance of the ABAP runtime environment so that these performance issues are
rarely a concern. We will investigate some basic guidelines for tuning perfor-
mance in Section 4.5, Tuning Performance.
4.2 Controlling Object Initialization with Constructors
Encapsulated objects rely on data stored in hidden attributes to keep track of their
internal state so that they can respond to method requests intelligently. There-
in
4 | Object Initialization and Cleanup
fore, it is vitally important to come up with a way to reliably supply the object's
attributes with data. Otherwise, you end up back in a procedural mode where
each method has to receive data via parameters or derive it from an external data
source (e.g., a database lookup, etc.). In either of
these
cases, the method becomes
more complex because you have to validate and perhaps derive data before you
can do any useful work.
Obviously, you want to avoid this kind of situation. However, to do so, you must
figure out a way to guarantee that the attributes of
a
class are properly initialized
before any calls are made to methods that depend on these attributes. Of course,
we could try to be disciplined in our approach and make sure that we call all of
the appropriate setter methods before using the object, but then we have to
remember to do it eveiy time an object is instantiated. In the best case, a lot of
redundant code is introduced. In the worst case, forgetting to call a method here
and there creates an even bigger problem by making it more difficult to figure out
where things went wrong. Clearly, we need a better method for initializing
objects.
Normally, whenever you declare a variable in an ABAP program, you don't have
to worry about creating it at runtime because this is handled for you automatically
by the ABAP runtime environment. For example, if you declare a global variable
in a program using a structure data type, you can immediately begin assigning
values to the components of that structure without having to issue a
CREATE
state-
ment. and so on. As you have seen, this is not the case for anonymous data
objects such as object instances. Here, we must use the
CREATE OBJECT
statement
to request that an object be created dynamically by the ABAP runtime environ-
ment. Prior to that request, we cannot use object reference variables in our pro-
gram because they do not point to a valid object instance.
One of the benefits of this kind of indirection is that it lets the ABAP runtime
environment take complete control of the creation process. Class developers are
allowed to interact with this process by creating a special method called a con-
structor. Constructors are called automatically by the ABAP runtime environment
after the object has been created but before control is returned to the program.
Inside the constructor, you can initialize all of the attributes in your class to
ensure that the object is created in a valid state.
Constructors are defined using a similar syntax to the one thatyou have used to
define normal methods in a class (see Listing 4.2). The only restriction here is that
112
Controlling Object Initialization with Constructors 4-2
you can only define importing parameters in the method signature. Ifyou think
about it, this makes sense because the constructor is called by the ABAP runtime
environment and not by the normal
CALL HETHOO
statement. In fact, it is not pos-
sible to call constructors directly in your programs.
METHODS constructor
IMPORTING [VALUE(]il i2 ...[)]
TYPE type [OPTIONAL]...
EXCEPTIONS exl ex2.
Listing 4.2 Syntax for Defining an Instance Constructor
Constructors can be created in global classes by clicking the CONSTRUCTOR button
in the Class Editor (see Figure 4.4).
Class Builder: Change Class ZCL_ACCOUNT
• E 1312X3
ISSSSD©^
S/ U
[tf
:
KX»'Trtwt niywuioi j: wy.ot^fQ" Contmxlcjjg CUMWrttnxttf
ZU_ACCOUKT tagMmMM/MM
M xl-d l M aoiaei
Figure 4.4 Creating Constructors for Global Classes
To demonstrate the usefulness of constructors, let's consider an example based
on an Account class that is used to represent various types of accounts at a bank.
In Listing 4.3, a class called icl_account has been created that provides a few
basic methods to view the current balance of the account as well as to withdraw
or deposit funds. The account details are stored in private attributes that do not
have associated setter methods. Instead, these attributes are initialized via a data-
base lookup inside the constructor method. Whenever a user instantiates an
object of type
1
cl_account, the user must provide a valid account number that is
used to lookup the relevant account details. In Chapter 8, Error Handling with
Exceptions, you will see how exceptions can be used to enforce this rule; for now.
you can simply assume that this is the case.
CLASS lcl_account DEFINITION.
TYPE POOLS: abap.
PUBLIC SECTION.
METHODS:
113