www.sap-press.

com 1
Design Patterns in Object-Oriented ABAP
Igor Barbaric
Contents
1 Introduction .................................................. 5
1.1

What are Design Patterns? ....................... 5
1.2

Communication in Patterns ...................... 6
1.3

Design Patterns in Software Design ......... 6
1.4

Success story: The Project and its
By-product ................................................ 7
Bad Application ........................................ 7
Starting with Design Patterns ................... 7
1.5

Conventions in this Book ......................... 7
1.6

Prerequisites ............................................. 8
Basics of Object-Oriented
Software Design ........................................ 8
Experience in ABAP Programming ........... 8
Reading UML Diagrams ............................ 8
1.7

Structure of the Book ............................... 9
Download ................................................. 9
Acknowledgements .................................. 9
2 The Demo Application .............................. 11
3 The Singleton Pattern ............................... 15
3.1

Denition .................................................. 15
3.2

Case-Study Problem: Instantiating
Application Only Once ............................. 15
3.3

Summary ................................................... 17
4 The Adapter Pattern .................................. 19
4.1

Denition .................................................. 19
4.2

Case-Study Problem: Application with
a Command Tree ...................................... 19
4.3

The Adapter in the Demo Application ..... 20
4.4

Interface lif_interface ................................ 20
Denition .................................................. 20
Types ......................................................... 20
node Attribute .......................................... 20
open Method ............................................ 20
get_sub_objects Method .......................... 21
menu_request Method ............................. 21
menu_select Method ................................ 21
4.5

Class lcl_application .................................. 21
Denition .................................................. 22
o_tree Attribute ........................................ 22
t_active_objects Attribute ........................ 22
constructor Method ................................. 23
run_application Method ........................... 23
on_double_click Method .......................... 25
on_expand_no_children Method ............. 25
on_menu_request Method ....................... 25
on_menu_select Method .......................... 26
4.6

Summary ................................................... 26
5 The Faade Pattern .................................... 27
5.1

Denition .................................................. 27
5.2

Case-Study Problem: Vendor-Specic
User-Dened Text on Purchase Order ...... 27
5.3

Class lcl_mod_facade ................................ 30
Denition .................................................. 31
constructor Method ................................. 31
lif_tree_object~open Method .................. 31
5.4

Class lcl_st_text_facade ............................ 31
Denition .................................................. 31
s_thead Attribute ...................................... 32
container Attribute ................................... 32
textedit Attribute ...................................... 32
constructor Method ................................. 32
on_toolbar_func_sel Method ................... 35
save Method ............................................. 35
free Method .............................................. 36
5.5

Summary ................................................... 36
2 Galileo Press 2006. All rights reserved.
Contents
6 The Composite Pattern ............................ 37
6.1

Denition .................................................. 37
6.2

Case-Study Problem: Organizing Flights
by Date ..................................................... 38
6.3

Class lcl_mod_composite ......................... 39
Denition .................................................. 39
Attributes .................................................. 39
constructor Method ................................. 40
lif_tree_object~get_sub_objects
Method ..................................................... 44
6.4

Summary ................................................... 46
7 The Decorator Pattern .............................. 47
7.1

Denition .................................................. 47
Confusion About Whats Preceding
and Whats Succeeding ............................ 48
7.2

Case-Study Problem: Lookup Data
for Internal Tables ..................................... 48
Reusability ................................................ 49
7.3

Class lcl_itab_dec ...................................... 50
Denition .................................................. 50
prec_decorator Attribute .......................... 50
dt_ref Attribute ......................................... 51
tt_fname_mappings Attribute .................. 51
constructor Method ................................. 52
refresh_data Method ................................ 52
get_elds Method ..................................... 53
7.4

Class lcl_itab_dec_vendor ......................... 53
Denition .................................................. 53
t_lfa1 Attribute ......................................... 54
constructor Method ................................. 54
refresh_data Method ............................... 54
get_elds Method ..................................... 57
7.5

Class lcl_itab_dec_st_text ......................... 59
Denition .................................................. 59
Attributes .................................................. 60
constructor Method ................................. 60
get_elds Method ..................................... 60
7.6

Other Decorators in the Application ........ 61
7.7

Implementation of the Decorator Pattern
in the Application ..................................... 61
7.8

Summary ................................................... 62
8 The Model-View-Controller ( MVC )
Pattern ............................................................ 63
8.1

Denition .................................................. 63
8.2

Case-Study Problem: Displaying
Table Data in Different Ways .................... 64
8.3

Class lcl_con ............................................. 66
Denition .................................................. 66
Attributes .................................................. 66
initialize Method ....................................... 67
8.4

Class lcl_mod ............................................ 67
Denition .................................................. 67
Interfaces .................................................. 68
dec_nal Attribute .................................... 68
dt_outtab Attribute .................................. 68
tabname Attribute .................................... 68
disp_struc_name Attribute ....................... 68
t_main_where Attribute ........................... 68
t_fcat Attribute ......................................... 68
caption Attribute ...................................... 68
constructor Method ................................. 69
init_controller Method ............................. 70
lif_tree_object~open Method .................. 71
lif_tree_object~menu_request Method .... 71
lif_tree_object~menu_select Method ...... 71
refresh Method ......................................... 71
save Method ............................................. 72
lif_tree_object~get_sub_objects
Method ..................................................... 72
8.5

Class lcl_con_alv ....................................... 72
Denition .................................................. 72
alv Attribute .............................................. 73
container Attribute ................................... 73
initialize Method ....................................... 73
on_toolbar Method .................................. 74
on_user_command Method ..................... 74
free Method .............................................. 75
8.6

Class lcl_con_alv_facade .......................... 75
Denition .................................................. 75
on_toolbar Method .................................. 75
on_user_command Method ..................... 75
8.7

Class lcl_con_dd ....................................... 76
Denition .................................................. 76
dd Attribute .............................................. 77
container Attribute ................................... 77
www.sap-press.com 3
Contents
initialize Method ....................................... 77
on_clicked Method ................................... 77
refresh_display Method ............................ 77
free Method .............................................. 80
8.8

Summary ................................................... 80
9 Summary ........................................................ 83
Index ................................................................ 85
www.sap-press.com 27
5 The Faade Pattern
5.1

Denition
According to the gang of four , Faade is intended to
provide a unied interface to a set of interfaces in a subsys-
tem. Faade denes a higher-level interface that makes the
subsystem easier to use
1
.
This means that we want to provide an interface to
some other system. Some possible reasons:

We want to translate an interface of a system to the
one that a particular group of developers will nd
easier to use. For example, if your ABAPers dont
know how to build a tool to access an external MS
SQL database, one of them can create the tool and
provide an ABAP class that interfaces the tool for
others.

We want to restrict the use of a system to a particular
subset of functionalities.
For example, lets say that you are a leader of an ABAP-
development team of four developers. They all have to
build different functionalities that communicate with a
machine in your companys factory. The machine pro-
duceslet us sayinjected plastic parts, and it works
with the intranet via some interface. The ABAPers cant
communicate with the machine unless they create some
kind of intermediate application.
You can stay aside, not interfere, and let them resolve
their problems in whichever way they can. Each of them
will create his or her application to interface with the
machine. In order to do that each one will all have to
learn a lot about the machine and its interface, which is
probably complicated, and build an application using a
tool other than ABAP that he or she is most familiar with.
1 Gamma, Helm, Johnson, Vlissides: Design Patterns: Elements
of Reusable Object-Oriented Software, Addison-Wesley, 1995.
What a waste of time! You have four people expending
their time on learning and then developing four differ-
ent applications to do more or less the same thing. You
will waste a lot of time and money, only to end up with
a mess that youll have to maintain. Figure 5.1 depicts
this result.
No good team leader would let this happen. Youd
be better off choosing the most appropriate person and
assigning him or her the task of creating an intermedi-
ate application, and then an ABAP class that serves as a
faade for other ABAPers to interface with the machine.
This way, only one person would have to learn every-
thing about the machine, and he or she would provide a
straightforward and easy-to-use interface for others. This
result is shown in Figure 5.2. If improvements or correc-
tions were needed, it would be in only one place. This
way you would save lots of developer days initially and
probably even more when it comes to maintenance.
5.2

Case-Study Problem: Vendor-Specic
User-Dened Text on Purchase Order
Imagine that one of your users comes to you with a
requirement like this: I want to be able to put a remark
or a note for a vendor on a purchase order. The remark
should be different for each vendor, and Id like to be
able to change it occasionally.
From the users perspective, this is a clear and simple
requirement. But how will you do it? Purchase order is
a SmartForm. Since you dont know how long the text
should be, you must not set any limits to number of char-
acters. Besides, the user might change his or her require-
ment ( users do that often ) and ask for some formatting
options, for example line breaks in the beginning, and
maybe even more complicated options later in the text.
28 Galileo Press 2006. All rights reserved.
5 The Faade Pattern
Engine
starter
Engine
stopper
Production
log
Status
flags
subsystem
java app
Temperature
controller
Pressure
controller
ABAP
application 1
ABAP
application 4
ABAP
application 3
ABAP
application 2
subsystem
VB app
subsystem
java app 2
subsystem
delphi app
SAP Web AS
SAP
system
Intermediate
applications
Machine
interface
Machine
Figure 5.1 Everyone Builds His or Her Own Application
zcl_machine_facade
Engine
starter
Engine
stopper
Production
log
Status
flags
subsystem
java app
Temperature
controller
Pressure
controller
ABAP
application 1
ABAP
application 4
ABAP
application 3
ABAP
application 2
SAP Web AS
SAP
system
Intermediate
application
Machine
interface
Machine
Figure 5.2 One Person Develops the Faade for Others
www.sap-press.com 29
5.2 Case-Study Problem: Vendor-Specic User-Dened Text on Purchase Order
The logical solution for this is to include a standard text
element in a SmartForm. You can include any standard
text in a SmartForm by using a special node. The text
name can be provided statically or dynamically. Since our
requirement presupposes different text for each vendor,
the text name should be composed dynamically by fol-
lowing naming conventions specially set for this purpose.
For example, you can name the standard text: ZPO_VEN_
<vendor_code>.
Then it would be easy to include a code node in a
SmartForm with a simple ABAP statement:
CONCATENATE 'ZPO_VEN_' lfa1-lifnr
INTO v_vendor_text_name.
And when you include a standard text node with name
created dynamically as &V_VENDOR_TEXT_NAME&, you
can be sure that this text will contain a remark exactly for
the particular vendor. Or can you?
Well, the SmartForm part is clear. This is how they
work; its consistent and exible. But how can we make
sure that users will know what to do? We can instruct
the user to go to the standard SAP transaction SO01
for maintaining standard texts and edit texts with care-
fully determined name as ZPO_VEN_ followed by a ven-
dor code. If users could follow these simple rules, that
approach would work ne. But if we analyze this process
more carefully, we realize its a pretty tough requirement
for an average user. There are lots of things to remember,
and to do:

Technical knowledge is required from users. They
must know how to use the standard transaction for
editing texts.

The text name is composed by a user manually. This
makes the system intolerant of typing errors: If a
single character is mistaken ( for example, one lead-
ing zero in vendor code is omitted, or underscore
in PO_VEN_ prex ), the text will be saved with no
warnings, but it wont appear at the purchase order
because it will be a completely different text than the
one expected by the purchase order. The user will get
confused and wont have idea of what happened. He
or she will come to you ( or someone of your staff ) to
complain, and youll tell him/her for the 10th time to
be careful with the text name. Is this a bad user or a
bad application?
Figure 5.3 and Figure 5.4 show how the standard trans-
actions for maintaining standard texts appear.
Figure 5.3 Transaction SO01Initial Screen
Figure 5.4 Transaction SO01Editing Text
This is initially the simplest solution for the developer,
since theres nothing to do except to modify the Smart-
Form a little. However, since user input errors are very
likely to happen without appropriate message, it annoys
users and intensies interaction between users and devel-
opers ( or administrators ). Even in the best case ( if we
assume no typos ), it puts an unacceptable load to users
and consumes too much of their time.
This is by far the worst solution. We should create
something better. For example, we could put navigation
to the SO01 transaction somewhere in the program by
using
30 Galileo Press 2006. All rights reserved.
5 The Faade Pattern
CALL TRANSACATION 'SO01'
AND SKIP FIRST SCREEN WITH...
while providing the text name automatically and even
skipping the initial screen.
This would be much better, but still not good enough.
The standard transaction is still too technical and offers
too many formatting options that are not needed for
this purpose. Besides, when returning to the main pro-
gram, one cannot skip the initial screen. This may not be
a major annoyance for users, but its still at least one click
too many.
By putting a Faade between the ABAP Objects world
and the standard texts repository in SAP, we could make
it extremely simple and straightforward for both users
and developers, with no possibility of errors. We can use
a text-editing control that pops up automatically, so that
the users never have to know the text name. They would
navigate to text by selecting a line and pressing an Edit
button ( as show in Figure 5.5 ).
Figure 5.5 Navigation from Program to Text
The control ( as shown in Figure 5.6 ) will have one text-
editor eld and just two buttons ( apart from the controls
standard toolbar ): Save and Close. The only formatting
would be line breaks, simply implemented by user press-
ing the Enter key.
Figure 5.6 The New Standard Text Editor
Moreover, if we create it as a dictionary class, we can use
it not only for this particular purpose, but in other appli-
cations too, whenever standard text editing is required.
This would be a faade between ABAP objects and
SAP standard objects that are not object-oriented. In
the demo application, we will maintain a dictionary
table ZDPS_FACADE with only one eld: LIFNRven-
dor code. It will be maintained as any other object at
the tree, by using an ALV grid control. The display struc-
ture which denes the grids output table will have two
more read-only elds: vendor name ( lled by the Decora-
tor described in Section 7.4 ) and text, which will be rst
100 characters of the standard text ( another Decorator,
described in Section 7.5 ). The ALV grid will have a special
button which will open the selected text in a new edit-
able control. This time it will be hosted by a dialog box
rather than by a docking container.
5.3

Class lcl_mod_facade
If you take a look at the class diagram in Chapter 2, you
will see that lcl_mod_facade is inherited from the
generic model class lcl_mod ( see Chapter 8 for details
on that model ). This means that its a specialized imple-
mentation of the generic table maintenance model, par-
ticularly maintaining the ZDPS_FACADE table.
The class is very simple. It has a constructor for initia-
tion, and the tree interface method open redened. It
is specic, becauseas opposed to all other objects
this one has to use a special version of the ALV grid class
and therefore needs a special controller LCL_CON_ALV_
FACADE. The specialty is one custom Edit button ( )
www.sap-press.com 31
5.4 Class lcl_st_text_facade
on the ALV grid toolbar that initializes editing standard
texts in a special textedit control.
Denition
CLASS lcl_mod_facade
DEFINITION INHERITING FROM lcl_mod.
PUBLIC SECTION.
METHODS: constructor,
lif_tree_object~open
REDEFINITION.
ENDCLASS.
constructor Method
The constructor denes the name of the dictionary table
to be maintained and the name of the dictionary struc-
ture which will be used for displaying data. The basic
node attributes are set and the chain of Decorators is cre-
ated ( read more on Decorators in Chapter 7 ).
METHOD constructor.
DATA: o_dec_vendor
TYPE REF TO lcl_itab_dec_vendor,
o_dec_st_text
TYPE REF TO lcl_itab_dec_st_text.
FIELD-SYMBOLS: <outtab>
TYPE STANDARD TABLE.
CALL METHOD super->constructor(
i_tabname =
'ZDPD_FACADE'
i_disp_struc_name =
'ZDPD_FACADE_DS'
i_title =
'Facade'(fac) ).
* node attributes
me->lif_tree_object~node-node_key =
'FACADE'.
me->lif_tree_object~node-text =
'Facade'(fac).
* create chain of decorators
ASSIGN me->dt_outtab->* TO <outtab>.
CREATE OBJECT:
o_dec_vendor
EXPORTING it_ref =
<outtab>,
o_dec_st_text
EXPORTING i_prec_dec =
o_dec_vendor,
me->dec_final
EXPORTING i_prec_dec =
o_dec_st_text.
ENDMETHOD.
lif_tree_object~open Method
The only reason we redened this method was to match
the model with the different controller.
METHOD lif_tree_object~open.
CALL METHOD
me->init_controller('LCL_CON_ALV_FACADE' ).
ENDMETHOD.
5.4

Class lcl_st_text_facade
This class is a faade between the object-oriented ABAP
world and SAPs non-object standard texts repository.
The standard text is a way for SAP Web AS engine to
store text of unknown size in the database. It allows for-
matting with special rules, and it can be used in many
ways, for example printing on forms. Each individual text
is accessed from an ABAP program by using the func-
tion modules READ_TEXT and SAVE_TEXT. In essence,
this class is a user interface for editing standard text that
wraps around these function modules to enable interac-
tion with object-oriented ABAP programs.
Denition
CLASS lcl_st_text_facade DEFINITION.
PUBLIC SECTION.
METHODS: constructor
IMPORTING is_thead TYPE thead
i_caption TYPE c.
PROTECTED SECTION.
TYPES: ty_t_text
TYPE STANDARD TABLE OF tdline.
DATA:
s_thead
TYPE thead,
container
TYPE REF TO
cl_gui_dialogbox_container,
32 Galileo Press 2006. All rights reserved.
5 The Faade Pattern
textedit
TYPE REF TO cl_gui_textedit.
METHODS:
on_toolbar_func_sel
FOR EVENT function_selected
OF cl_gui_toolbar
IMPORTING fcode sender,
save,
free.
ENDCLASS.
As you can see, the class consists of three attributes and
four methods.
s_thead Attribute
This is a structure of type THEAD, and it represents the
key values for accessing standard texts. The function
modules READ_TEXT and SAVE_TEXT have parameters
of the very same type.
container Attribute
This is a dialog-box container for the textedit control
to open in. The only reason for the container to be
an attribute ( rather than a methods local variable ) is to
enable its destruction by the free method.
textedit Attribute
This is a standard textedit control. The same explanation
applies regarding destruction as for container.
constructor Method
Since this class has no other purpose except to let users
edit standard text, I didnt think that we needed a special
method to open a user interface. The text editor can be
opened directly in the constructor.
First we must create the main container. For a change,
lets make it a dialog box rather than a docking container.
The text editor looks good in it.
CREATE OBJECT me->container
EXPORTING top = 50
left = 200
height = 150
width = 500
caption = i_caption.
Actually, we need two containers: one for the text editor
and another for the toolbar. The simple splitter accom-
plishes that, and we create it within the dialog box that
we have just created.
CREATE OBJECT o_splitter
EXPORTING
parent = me->container
orientation =
o_splitter->orientation_vertical
sash_position = 10. "percentage of
" containers
Now we can put a toolbar in the splitters upper con-
tainer and append two buttons: Save and Close.
CREATE OBJECT o_toolbar
EXPORTING parent =
o_splitter->top_left_container.
CALL METHOD o_toolbar->add_button(
fcode = 'SAVE'
icon = icon_system_save
butn_type = cntb_btype_button ).
CALL METHOD o_toolbar->add_button(
fcode = 'CLOSE'
icon = icon_close
butn_type = cntb_btype_button ).
Of course, we need to register methods for handling
events that the toolbar res when the buttons are
pressed.
REFRESH t_events.
s_event-eventid =
cl_gui_toolbar=>m_id_function_selected.
s_event-appl_event = 'X'.
APPEND s_event TO t_events.
CALL METHOD
o_toolbar->set_registered_events
EXPORTING events = t_events.
SET HANDLER:
me->on_toolbar_func_sel
FOR o_toolbar.
The textedit control is placed in the splitters bottom
container.
www.sap-press.com 85
Index
A
Adapter 11, 19, 26
class lcl_application 21
interface lif_interface 20
aggregation 8
Alexander, Christopher 6
ALV grid 12, 30, 48, 49, 50, 59, 63, 64,
67, 68, 70, 71, 72, 74, 75, 80
C
CL_DD_DOCUMENT 65, 66, 70, 75
CL_GUI_ALV_GRID 64, 66, 71, 72
CL_GUI_DOCKING_CONTAINER 72
CL_GUI_SIMPLE_TREE 66
command tree 19
Company Decorator 61
Composite 11, 37, 46
class lcl_mod_composite 39
context menu 21
Controller 64
D
data-reference objects 66
Decorator 11, 12, 30, 47, 62
class lcl_itab_dec 50
class lcl_itab_dec_company 61
class lcl_itab_dec_material 61
class lcl_itab_dec_st_text 59
class lcl_itab_dec_vendor 53
implementation 61
naming conventions 48
demo application 11
Design Patterns
definition 5
in software design 6
Dynamic Document 12, 63, 65, 70, 75,
80
F
Faade 11, 27, 36, 59
class lcl_mod_facade 30
class lcl_st_text_facade 31
field mappings table 52
G
gang of four 6, 15, 19, 27, 37, 47, 63
I
inheritance 8
internal table 48
L
lcl_application 15, 16, 21, 70
lcl_con 66, 71
lcl_con_alv 66, 71
lcl_con_alv_facade 74
lcl_con_dd 66, 75
lcl_itab_dec 50, 53
lcl_itab_dec_company 61
lcl_itab_dec_material 61
lcl_itab_dec_st_text 59
lcl_itab_dec_vendor 53
lcl_mod 50, 61, 67
lcl_mod_composite 39, 68
lcl_mod_facade 30, 62
lcl_st_text_facade 31
lif_interface 20
lookup data, internal table 48
M
Material Decorator 61
model 63
Model-View-Controller MVC
multiple instantiation 16
MVC 11, 12, 63, 80
class lcl_con 66
class lcl_con_alv 71
class lcl_con_alv_facade 74
class lcl_con_dd 75
class lcl_mod 67
R
reusability 49
S
SAPscript 63
Singleton 11, 12, 15, 17, 22
skins 80
SmartForms 63
Standard Text Decorator 59
state 64
sy-subrc 60
T
text editor 30
transaction SO01 29
U
UML Class Diagram 8
Unified Modeling Language (UML) 8
usage 8
user-defined text 27
V
Vendor Decorator 53
view 63