Wood J. Object-Oriented Programming with ABAP Objects

Подождите немного. Документ загружается.

2 | Working with Objects

START-OF-SELECT ION.

WRITE: / 'You entered: p_phone.

FORM check_phone_number.

* Local Data Declarations:

DATA: lr_regex TYPE REF TO cl_abap_regex.

lr_matcher TYPE REF TO cl_abap_matcher.

* Create the regular expression:

CREATE OBJECT 1r.regex

EXPORTING

pattern - •$\dl3l$\dl3)-\dl4|'.

* Check to see if the phone number matches the

* regular expression:

CREATE OBJECT lr_matcher

EXPORTING

regex - lr_regex

text - p_phone.

IF lr_matcher->match( ) NE abap_true.

MESSAGE 'Enter phone number in (xxx)xxx-xxxx format.'

TYPE 'E\

ENDIF.

ENDFORM.

Listing 2.24 Using Global Classes in ABAP Programs

As you can see in Listing 2.24, you can perform a fairly complex validation with

a handful of statements — the classes perform the heavy lifting. Therefore, even

if you are not yet an expert in creating

classes,

you can still put classes to work for

you immediately in your programs.

2.6 UAAL Tutorial: Object Diagrams

Section 1.6, UML Tutorial: Class Diagram Basics, showed how class diagrams can

be used to specify the static architecture of an object-oriented system. Most of the

time, these diagrams are straightforward and easy to interpret. However, some-

times the relationship between certain classes is not so intuitive. In these cases,

object diagrams can be used to depict a snapshot or simulation of the actual

objects created in reference to these classes at runtime. Often, just seeing an

UML Tutorial: Object Diagrams

example of how the actual objects are configured at runtime can shed some light

on the nature of complex class relationships.

Figure 2.31 illustrates a portion of

class diagram that shows the recursive aggre-

gation relationship between a bill of material (BOM) document and its items. The

diamond on the Material

BOH

side of the association is used to indicate that the

BOM is an aggregate, containing 0 or more items.

MaterialBOM

- material

-plant

...

items items

Figure 2.31 Class Diagram Showing Material BOM Aggregation

A BOM contains a series of items (or components) that are used to assemble a fin-

ished product. In complex engineering scenarios, it is not uncommon for a BOM

to contain items that are also complex assemblies. Figure 2.32 demonstrates an

object diagram that shows a BOM object for a laptop computer that is being pro-

duced by a computer hardware manufacturer. The laptop object is comprised of

multiple components (e.g., a hard drive, motherboard, LCD display, etc.) The

motherboard object is also an aggregate, containing a CPU and chipset.

As you can see from Figure 2.32, object diagrams are vety similar to class dia-

grams in many respects. However, in an object diagram, the rectangular boxes

represent object instances instead of

classes.

Figure 2.33 shows the basic notation

for specifying objects in an object diagram. In the top box. you provide the name

of the object as well as the type of

class

the object is created in reference to. The

lower box is optional, allowing you to provide additional runtime details about

the object (i.e., its current state).

Object diagrams can display as many objects as needed to illustrate the class/

object relationships. The diagram is considered to be a viewport into the system

at a particular point in time. Objects are created and destroyed in programs all of

the time, so it is important not to get hung up on trying to illustrate eveiy possi-

ble object that will be created in the system at runtime. If one diagram cannot

2 | Working with Objects

fully describe the relationship, additional diagrams can be used to show the pro-

gression of the object configuration as the program continues to run.

Figure 2.32 Object Diagram Showing BOM for a Laptop Computer

Object Name: Class Type

attributes "value*

attributes "value"

Figure 2.33 Object Instance Notation in Object Diagrams

2.7 Summary

At this point, you should have learned enough ABAP Objects syntax to begin

writing object-oriented programs in ABAP. However, although this chapter pro-

vided a nuts-and-bolts description of classes and objects, it only scratched the sur-

face with regards to the potential benefits that can be obtained by adopting an

object-oriented approach to your program designs.

In the next chapter, we will begin to explore some of these features by examining

the concepts of encapsulation and implementation hiding.

PART II

Core Concepts

Classes are abstractions that can be used to extend the functionality of a

programming language by introducing user-defined types. Encapsulation

and implementation hiding techniques are used to simplify the way devel-

opers interact with these types, making object-oriented programs easier to

understand, maintain, and enhance. In this chapter, you will learn how to

apply these techniques to your ABAP Objects classes.

3 Encapsulation and Implementation

Hiding

One of the most obvious ways to speed up the software development process is to

leverage pre-existing code. However, while most projects strive to build reusable

code libraries, few actually succeed in delivering modules that can be used out-

side of the context in which they were originally conceived. In most cases, this is

because the module is too lightly coupled with its surrounding environment. Of

course, without clairvoyance, it is difficult to anticipate how and when a given

module might be reused in other contexts. Instead of trying to predict future

usage types, pragmatic developers look for ways to build autonomous compo-

nents that can think and act on their own within a defined set of boundaries.

In this chapter, we will investigate ways to breathe life into objects by learning

how to exploit some of the potential benefits associated with encapsulating data

and behavior together within a class. Along the way, we will explore the use of

access control mechanisms that help to shape the interfaces of these classes to

make them easier to modify and reuse in other contexts.

3.1 Lessons Learned from the Procedural Approach

Contraiy to popular belief, many core object-oriented concepts are based on sim-

ilar notions that are rooted in the procedural programming paradigm. In both dis-

ciplines, the basic goal is to bring order and reliability to the software develop-

ment process. Clearly, there is a lot to be learned from procedural and structured

3 | Encapsulation and Implementation Hiding

programming techniques. However,

you will see in this section, there are cer-

tain limitations to the procedural approach that you must overcome to improve

the overall quality of your software designs.

3.1.1 Decomposing Functional Decomposition

Procedural developers typically formulate their program designs using a process

called functional decomposition. This term comes from the mathematics world,

where a mathematical function is broken down into a series of smaller functions

that are easier to understand. From a development perspective, functional

decomposition refers to the process of decomposing a complex program into a

series of smaller modules (or procedures). One common approach for discovering

these procedures is to scan through the verbs used to describe the actions of

pro-

gram within the functional requirements. These actions represent the steps a pro-

gram must take to meet its objectives. After all of the steps have been identified,

they must be composed into a main program that is responsible for making sure

that procedures are called in the right order, and so on. The process of organizing

and refining the main program is sometimes called step-wise refinement.

For small- to medium-sized programs, this strategy works pretty well. However,

as programs start to branch out and grow in complexity, the design tends to

become unwieldy as the main program becomes saddled with too many respon-

sibilities. Much of this burden stems from the fact that the main program must be

accountable for all of the data used by the various procedures.

Ideally, you want to be able to delegate some of these management duties to pro-

cedures, but for that to happen, the procedures need to be smart enough to figure

certain things out on their own — and that requires data. Of course, a main pro-

gram can pass instructions to a procedure via parameters, but the downside to

this approach is that cluttering up a procedure's parameter interface causes it to

be tightly coupled to the calling program that provides the data. These kinds of

dependencies cause all kinds of maintenance problems and also make it much

more difficult to reuse the procedures in other environments. On the other hand,

liberal use of

global

data within procedures is also dangerous. For example, think

about a program that has a series of procedures that all share and manipulate a

piece of global data. If you arc asked to change the sequence of the procedure

calls,

can

you be certain that this change will not result in some kind of unpredict-

able data corruption scenario?

Lessons Learned from the Procedural Approach

As you can see, although functional decomposition helps to break a program

down into smaller chunks (i.e., procedures) that are easier to understand, it does

not necessarily guarantee that a program will hold up to the changing require-

ments that inevitably creep in over time. Clearly, a better way of structuring soft-

ware is needed.

3.1.2 Case Study: A Procedural Code Library in ABAP

To demonstrate some of the problems associated with functional decomposition,

let's consider an example that shows how you might construct a Date utility

libraiy using procedural function groups written in ABAP. Prior to SAP R/3

Release 4.0, most reusable code libraries written in ABAP were built using func-

tion groups. In some respects, function groups are analogous to classes in the

sense thatyou can define global data (attributes) and function modules (methods)

centrally within a function pool inside the ABAP Repositoiy. However, this anal-

ogy breaks down when you consider the fact that you cannot load multiple

instances of

function group inside your program'. This limitation makes it diffi-

cult for function module developers to work with global data in the function

group because additional logic is required to partition the data into separate work

areas (i.e., instances).

The typical workaround for this shortcoming is to store the data locally within the

calling program and create a series of stateless function modules to operate on the

data. Stateless function modules do not have any recollection of prior invoca-

tions; each time thatyou call them, you must pass in all of the data that they will

need to perform their task(s).

Listing 3.1 shows a simple function group called

ZOATE.AP!

that defines the Date

libraiy. Normally, this libraiy would contain many other function modules to

maintain the components of the date, display the date in various localized for-

mats, and so on. However, for the purposes of this discussion, it simply describes

a single function module called

Z_DATE_SET_OAY

that is used to assign the day

value for the date.

1 Whenever you call a function module from a particular function group inside your program, the

global data from the function group are loaded into the memory of the internal session of your

program. Any subsequent calls to function modules within that function group will share the

same global data allocated whenever the first function module was called.

3 | Encapsulation and Implementation Hiding

FUNCTION-POOL zdate.api.

FUNCTION z_date_set_month.

ENDFUNCTION.

FUNCTION z_date_set_day.

* Local Interface IMPORTING VALUE (iv_day) TYPE I

* CHANGING (cs.date) TYPE SCALS_OATE

EXCEPTIONS invalid_date

OATA: lv_month_end TYPE 1. "Last Oay of Month

CASE is_date-month.

WHEN 1.

lv_month_end - 31.

WHEN 2.

ENOCASE.

IF iv_day LT 1 OR iv_day GT 1v_month_end.

RAISE invalid_date.

ELSE.

cs_date-day - iv_day.

ENDIF.

ENDFUNCTION.

Listing 3.1 A Simple Date Library Built with Function Croups

The logic inside function module Z_OATE_SET_DAY is pretty straightforward. First,

the value of importing parameter IV_DAY is examined to ensure that the DAY field

in structure CS_0ATE (see Figure 3.1) is not assigned an invalid value based on the

current month assignment (handling leap year situations, etc.). Assuming all of

the validations are passed, the DAY field is updated in the CS_DATE structure; oth-

erwise, an exception is thrown, and the update does not occur.

Now that we have established our simple Date library, let's think about how we

might handle a couple of maintenance scenarios that might pop up over time:

• First, imagine that you are asked to expand the functionality of the Date library

to also keep track of time. Here, you are faced with a dilemma. Changing the

representation of the date (i.e., switching to a structure containing both date

and time components) requires wholesale changes not only to the function

modules but also to the programs that call them.

Lessons Learned from the Procedural Approach

• Next, consider a program that is using the Date library to output a date in var-

ious formats. You are assigned a defect for this program because it is displaying

invalid date values (e.g., 02/31/2009). During your investigation, you discover

that the invalid day value was not set by function

Z_DATE_SET_DAY,

but rather

by an invalid assignment that was made to the

DAY

field in the local date struc-

ture maintained in the calling program.

& BBS

| Slrutftjre Edit Goto mim<W) Boat EtMconmert Sptem Help ^m

Dictionary: Display Structure

••

MAM. ^COG

MM DH

IH^^IR—ZZ]

Structure SCALS.OATE

Snort Descnpton

Oenwal Oate Sfructure

m. v-7';y components I Entry helprt reck CiriencQuantfrfleldt

Id I I __|

{RTy [component

type

|o»> [Length [oecim TsnortOe*tnpt>on

r SC<L YEAR NUHC 4

Calendar

Year

' r $t»L "CW MOBC 2

Calendar norm

' r~ SCAL PAT nunc 2

Calendar

Day

SOL ccwnMHEft CHAR 20 0Data Container

for

Adationai

Date Er**«

SB' —mmm

Figure 3.1 ABAP Dictionary Structure SCALS_DATE

The previous maintenance scenarios demonstrate some serious flaws in our date

libraiy. Because the data object containing the date fields is managed outside of

the function group (i.e., in the calling programs), we cannot control the values

that are assigned to it externally. Within the

SCALS_DATF

structure definition, the

field

DAY

is simply a two-digit numeric character with a valid number range of 00-

99; the semantic meaning of the

DAY

component is defined within the logic of

function

Z_DATE_SET_DAY.

Given the amount of effort invested in getting the logic

for function

Z_OATE_SET_DAY

right, we want to make sure that all updates to the

OAY

field pass through this function so that we can avoid data corruption and code

duplication. Moreover, we also need to figure out a way to simplify the function

interface so that changes to the internal data representation of the date do not

affect programs that are already using this Date libraiy in production.