• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Sappress object oriented_programming_with_abap_objects
 

Sappress object oriented_programming_with_abap_objects

on

  • 1,506 views

 

Statistics

Views

Total Views
1,506
Views on SlideShare
1,502
Embed Views
4

Actions

Likes
0
Downloads
164
Comments
0

1 Embed 4

http://efesto.cloudapp.net 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Sappress object oriented_programming_with_abap_objects Sappress object oriented_programming_with_abap_objects Document Transcript

    • James WoodObject-Oriented Programmingwith ABAP™ Objects Bonn Boston
    • Contents at a GlancePART I Basics1 Introduction to Object-Oriented Programming ........................... 232 Working with Objects ................................................................ 41PART II Core Concepts3 Encapsulation and Implementation Hiding ................................. 894 Object Initialization and Cleanup ............................................... 1075 Inheritance ................................................................................. 1276 Polymorphism ............................................................................ 1557 Component-Based Design Concepts ........................................... 1838 Error Handling with Exceptions .................................................. 2019 Unit Testing with ABAP Unit ...................................................... 233PART III Case Studies10 Working with the SAP List Viewer .............................................. 25711 ABAP Object Services ................................................................. 27912 Working with XML ..................................................................... 30313 Where to Go From Here ............................................................. 329APPENDIXA Debugging Objects ..................................................................... 333B The Author ................................................................................. 343
    • ContentsIntroduction ..................................................................................................... 15PART I: Basics1 Introduction to Object-Oriented Programming ........................ 23 1.1 The Need for a Better Abstraction .................................................. 23 1.2 Classes and Objects ........................................................................ 24 1.3 Establishing Boundaries .................................................................. 27 1.4 Reuse ............................................................................................. 29 1.4.1 Composition ...................................................................... 29 1.4.2 Inheritance ........................................................................ 30 1.4.3 Polymorphism .................................................................... 31 1.5 Object Management ....................................................................... 33 1.6 UML Tutorial: Class Diagram Basics ................................................ 33 1.6.1 Classes ............................................................................... 34 1.6.2 Attributes .......................................................................... 36 1.6.3 Operations ......................................................................... 37 1.6.4 Associations ....................................................................... 38 1.6.5 Notes ................................................................................. 39 1.7 Summary ........................................................................................ 392 Working with Objects ................................................................ 41 2.1 Syntax Overview ............................................................................. 41 2.1.1 Defining Classes ................................................................. 42 2.1.2 Declaring Components ....................................................... 42 2.1.3 Implementing Methods ...................................................... 51 2.2 Creating and Using Objects ............................................................. 52 2.2.1 Object References .............................................................. 52 2.2.2 Creating Objects ................................................................ 53 2.2.3 Object Reference Assignments ........................................... 53 2.2.4 Working with Instance Components .................................. 54 2.2.5 Working with Class Components ........................................ 57 2.2.6 Creating Complex Expressions Using Functional Methods ............................................................................ 61 7
    • Contents 2.3 Building Your First Object-Oriented Program .................................. 64 2.4 Getting Started with the Class Builder ............................................. 71 2.4.1 Class Pools ......................................................................... 71 2.4.2 Accessing the Class Builder ................................................ 71 2.4.3 Creating Classes ................................................................. 72 2.4.4 Defining Class Components ................................................ 74 2.4.5 Editing the Class Definition Section Directly ....................... 82 2.5 Case Study: Working with Regular Expressions ............................... 82 2.6 UML Tutorial: Object Diagrams ...................................................... 84 2.7 Summary ........................................................................................ 86PART II: Core Concepts3 Encapsulation and Implementation Hiding ............................... 89 3.1 Lessons Learned from the Procedural Approach .............................. 89 3.1.1 Decomposing Functional Decomposition ........................... 90 3.1.2 Case Study: A Procedural Code Library in ABAP ................. 91 3.1.3 Moving Toward Objects ..................................................... 94 3.2 Data Abstraction with Classes ......................................................... 94 3.3 Defining Component Visibilities ...................................................... 95 3.3.1 Visibility Sections ............................................................... 96 3.3.2 Friends ............................................................................... 99 3.4 Hiding the Implementation ............................................................. 101 3.5 Designing by Contract .................................................................... 102 3.6 UML Tutorial: Sequence Diagrams .................................................. 103 3.7 Summary ........................................................................................ 1054 Object Initialization and Cleanup .............................................. 107 4.1 Creating Objects ............................................................................. 107 4.2 Controlling Object Initialization with Constructors .......................... 111 4.3 Taking Control of the Instantiation Process ..................................... 117 4.4 Garbage Collection ......................................................................... 121 4.5 Tuning Performance ....................................................................... 122 4.5.1 Design Considerations ........................................................ 123 4.5.2 Lazy Initialization ............................................................... 123 4.5.3 Reusing Objects ................................................................. 124 4.5.4 Using Class Attributes ........................................................ 1248
    • Contents 4.6 UML Tutorial: State Machine Diagrams .......................................... 125 4.7 Summary ........................................................................................ 1265 Inheritance ................................................................................. 127 5.1 Generalization and Specialization ................................................... 128 5.2 Inheriting Components ................................................................... 133 5.2.1 Designing the Inheritance Interface .................................... 133 5.2.2 Visibility of Instance Components in Subclasses ................. 135 5.2.3 Visibility of Class Components in Subclasses ....................... 136 5.2.4 Redefining Methods ........................................................... 136 5.2.5 Instance Constructors ......................................................... 138 5.2.6 Class Constructors .............................................................. 140 5.3 The Abstract and Final Keywords .................................................... 140 5.3.1 Abstract Classes and Methods ............................................ 140 5.3.2 Final Classes ....................................................................... 143 5.3.3 Final Methods .................................................................... 144 5.4 Inheritance Versus Composition ..................................................... 145 5.5 Using the Refactoring Assistant ....................................................... 148 5.6 UML Tutorial: Advanced Class Diagrams Part I ................................ 150 5.6.1 Generalization .................................................................... 150 5.6.2 Dependencies and Composition ......................................... 151 5.6.3 Abstract Classes and Methods ............................................ 152 5.7 Summary ........................................................................................ 1536 Polymorphism ............................................................................ 155 6.1 Object Reference Assignments Revisited ......................................... 155 6.1.1 Static and Dynamic Types .................................................. 156 6.1.2 Casting ............................................................................... 158 6.2 Dynamic Method Call Binding ........................................................ 160 6.3 Interfaces ....................................................................................... 163 6.3.1 Interface Inheritance Versus Implementation Inheritance ... 164 6.3.2 Defining Interfaces ............................................................. 165 6.3.3 Implementing Interfaces .................................................... 167 6.3.4 Working with Interfaces ..................................................... 170 6.3.5 Nesting Interfaces .............................................................. 177 6.4 UML Tutorial: Advanced Class Diagrams Part II .............................. 180 6.4.1 Interfaces ........................................................................... 180 9
    • Contents 6.4.2 Providing and Required Relationships with Interfaces ........ 181 6.4.3 Static Attributes and Methods ........................................... 182 6.5 Summary ........................................................................................ 1827 Component-Based Design Concepts ......................................... 183 7.1 Understanding the SAP Component Model .................................... 183 7.2 The Package Concept ..................................................................... 185 7.2.1 What Is a Package? ............................................................ 186 7.2.2 Creating and Organizing Packages Using the Package Builder ............................................................................... 188 7.2.3 Embedding Packages ......................................................... 191 7.2.4 Defining Package Interfaces ............................................... 192 7.2.5 Creating Use Accesses ........................................................ 194 7.2.6 Performing Package Checks ................................................ 195 7.2.7 Package Design Concepts ................................................... 196 7.3 UML Tutorial: Package Diagrams .................................................... 197 7.4 Summary ........................................................................................ 1998 Error Handling with Exceptions ................................................. 201 8.1 Lessons Learned from Prior Approaches .......................................... 201 8.2 The Class-Based Exception Handling Concept ................................. 203 8.3 Dealing with Exceptions ................................................................. 205 8.3.1 Handling Exceptions .......................................................... 205 8.3.2 Cleaning up the Mess ......................................................... 209 8.4 Raising and Forwarding Exceptions ................................................. 210 8.4.1 System-Driven Exceptions .................................................. 211 8.4.2 The RAISE EXCEPTION Statement ...................................... 211 8.4.3 Propagating Exceptions ...................................................... 215 8.5 Creating Exception Classes .............................................................. 219 8.5.1 Understanding Exception Class Types ................................. 220 8.5.2 Local Exception Classes ...................................................... 221 8.5.3 Global Exception Classes .................................................... 221 8.5.4 Defining Exception Texts .................................................... 223 8.5.5 Mapping Exception Texts to Message IDs .......................... 227 8.6 UML Tutorial: Activity Diagrams ..................................................... 229 8.7 Summary ........................................................................................ 23110
    • Contents9 Unit Testing with ABAP Unit ..................................................... 233 9.1 ABAP Unit Overview ...................................................................... 234 9.1.1 The Need for Unit Testing Frameworks .............................. 234 9.1.2 Unit Testing Terminology ................................................... 235 9.1.3 Understanding How ABAP Unit Works ............................... 236 9.2 Creating Unit Test Classes ............................................................... 237 9.2.1 Test Attributes ................................................................... 238 9.2.2 Test Methods ..................................................................... 239 9.2.3 Managing Fixtures ............................................................. 239 9.2.4 Generating Test Classes for Global Classes .......................... 240 9.3 Case Study: Creating a Unit Test in ABAP Unit ................................ 241 9.4 Executing Unit Tests ....................................................................... 244 9.4.1 Integration with the ABAP Workbench .............................. 245 9.4.2 Integration with the Code Inspector ................................... 245 9.5 Evaluating Unit Test Results ............................................................ 246 9.6 Moving Toward Test-Driven Development ..................................... 247 9.7 UML Tutorial: Use Case Diagrams ................................................... 248 9.7.1 Use Case Terminology ........................................................ 249 9.7.2 An Example Use Case ......................................................... 249 9.7.3 The Use Case Diagram ....................................................... 251 9.7.4 Use Cases for Requirements Verification ............................ 252 9.7.5 Use Cases and Testing ........................................................ 252 9.8 Summary ........................................................................................ 253PART III: Case Studies10 Working with the SAP List Viewer ............................................ 257 10.1 Overview of the SAP Control Framework ........................................ 257 10.1.1 Control Framework Architecture ........................................ 258 10.1.2 Survey of Available Controls ............................................... 259 10.2 Overview of the ALV Object Model ................................................ 260 10.3 Getting Started with the Flight Query Report .................................. 261 10.3.1 Understanding the Report Requirements ............................ 261 10.3.2 Report Design Using the MVC Design Pattern .................... 261 10.3.3 Developing the Flight Model Class ..................................... 262 10.3.4 Developing the Report Controller Class .............................. 264 10.3.5 Implementing the Report View .......................................... 267 11
    • Contents 10.4 Event Handling with the ALV Object Model ................................... 271 10.4.1 Integrating Event Handler Methods into the Controller ...... 271 10.4.2 Registering Event Handler Methods ................................... 272 10.4.3 Responding to Events ........................................................ 273 10.4.4 Triggering Events on the Frontend ..................................... 274 10.4.5 Timing of Event Handling ................................................... 275 10.5 UML Tutorial: Communication Diagrams ........................................ 275 10.6 Summary ........................................................................................ 27711 ABAP Object Services ................................................................ 279 11.1 Object-Relational Mapping Concepts ............................................. 280 11.2 Persistence Service Overview .......................................................... 280 11.2.1 Managed Objects ............................................................... 282 11.2.2 Mapping Concepts ............................................................. 284 11.2.3 Understanding the Class Agent API .................................... 285 11.3 Building Persistent Classes .............................................................. 286 11.3.1 Creating a Persistent Class in the Class Builder ................... 287 11.3.2 Defining Persistent Attributes with the Mapping Assistant ............................................................................ 288 11.3.3 Working with Object References ........................................ 292 11.4 Working with Persistent Objects ..................................................... 293 11.4.1 Creating New Persistent Objects ........................................ 294 11.4.2 Reading Persistent Objects Using the Query Service ........... 295 11.4.3 Updating Persistent Objects ............................................... 297 11.4.4 Deleting Persistent Objects ................................................ 298 11.5 UML Tutorial: Advanced Sequence Diagrams .................................. 298 11.5.1 Creating and Deleting Objects ........................................... 298 11.5.2 Depicting Control Logic with Interaction Frames ................ 300 11.6 Summary ........................................................................................ 30112 Working with XML .................................................................... 303 12.1 XML Overview ............................................................................... 303 12.1.1 Why Do We Need XML? .................................................... 304 12.1.2 Understanding XML Syntax ................................................ 305 12.1.3 Defining XML Semantics .................................................... 307 12.2 XML Processing Concepts ............................................................... 309 12.2.1 Processing XML Using a Parser ........................................... 30912
    • Contents 12.2.2 Modeling XML with the DOM ........................................... 310 12.2.3 Features of the iXML Library .............................................. 310 12.3 Case Study: Developing a Reading List ADT .................................... 311 12.4 Case Study: Building an XML Document ......................................... 314 12.5 Case Study: Reading an XML Document ......................................... 320 12.6 UML Tutorial: Advanced Activity Diagrams ..................................... 325 12.7 Summary ........................................................................................ 32713 Where to Go From Here ............................................................. 329APPENDIXA Debugging Objects .................................................................... 333 A.1 Debugging Objects Using the Classic ABAP Debugger .................... 333 A.1.1 Displaying and Editing Attributes ....................................... 333 A.1.2 Tracing Through Methods .................................................. 336 A.1.3 Displaying Events and Event Handler Methods ................... 336 A.1.4 Viewing Reference Assignments for an Object .................... 337 A.1.5 Troubleshooting Class-Based Exceptions ............................ 338 A.2 Debugging Objects Using the New ABAP Debugger ....................... 340B The Author .................................................................................. 343Index ................................................................................................................ 345 13
    • IntroductionWith all of the hype surrounding object-oriented programming, it can be difficultto separate the truth from fantasy. If you have picked up this book, it is likely thatyou have developed an interest in learning more about what the excitement is allabout. This book provides the answers that you are looking for.The goal of this book is to teach you how to think about writing ABAP™ softwarefrom an object-oriented point-of-view. After reading this book, you will beequipped to work with many of the new and exciting ABAP-based technologiesbased on ABAP Objects such as Web Dynpro, ABAP Object Services, SAP® Busi-ness Workflow, and Web Services.Target Group and PrerequisitesThis book is intended for ABAP application developers that have some basic expe-rience writing ABAP programs using the ABAP Development Workbench. BasicABAP language concepts are not covered in this book, so you have not workedwith ABAP before, read ABAP Objects – ABAP Programming in SAP NetWeaver(SAP PRESS, 2007). Of course, in an introductory book such as this, no priorobject-oriented experience is expected.The object-oriented extensions to the ABAP programming language (i.e., theObjects part of ABAP Objects) were made available in SAP R/3 4.6C. Therefore,you do not have to have the latest version of the SAP NetWeaver ApplicationServer ABAP (AS ABAP) to start working with most of the object-oriented con-cepts described in this book. However, additions to the standard that were addedin subsequent releases are pointed out where appropriate.If you want to reproduce the examples in the book and don’t have access to an ASABAP instance, you can download a trial version from the SAP Developer Net-work (http://sdn.sap.com) that you can install on your local PC. From the mainpage, select Downloads Software Downloads SAP NetWeaver MainReleases. There, you will find several versions of the AS ABAP that you can installdepending on your preferred operating system, and so on. Each download pack- 15
    • Introductionage comes with a set of instructions to help you get started. The SAP DeveloperNetwork forums can also provide useful tips if you run into problems.Structure of the BookIn many ways, this was a very difficult book to write. Doing a topic like this jus-tice requires a healthy balance between theoretical and practical concepts, somany practical examples are included that illustrate theoretical concepts.The first part of the book helps get you started quickly by describing basic object-oriented concepts using a series of simple object-oriented programs. The secondpart of the book covers core object-oriented concepts such as encapsulation,inheritance, and polymorphism. The final part of the book teaches you how toapply these concepts using the tools and services available in the SAP NetWeaverApplication Server.The end of each chapter includes a brief tutorial on the Unified Modeling Lan-guage (UML). These tutorials show you how to express your object-orienteddesigns using a graphical notation that is commonly used throughout the indus-try.In detail, the chapters provide the following content: Chapter 1: Introduction to Object-Oriented Programming Object-oriented programming is steeped in theory. Therefore, before we delve into the creation of classes, we need to review this theory so that you can understand how everything fits together. The concepts described in this chap- ter provide you with the foundation you need to start developing classes. Chapter 2: Working with Objects This chapter reinforces the theoretical concepts covered in Chapter 1 by allow- ing you to get your hands dirty by creating some simple object-oriented pro- grams written in ABAP Objects. Here, we will spend a lot of time looking at the ABAP Objects syntax for defining classes, methods, and so on. This syntax is highlighted by a series of examples that illustrate how classes can be used in practical situations. Chapter 3: Encapsulation and Implementation Hiding This chapter introduces you to two important concepts in object-oriented design: encapsulation and implementation hiding. First, the importance of these concepts is demonstrated by observing some problems with code librar-16
    • Introductionies developed using procedural methods. Then, you will learn how to avoidthese problems in class libraries through the use of access specifiers. Finally,we will take a step back and look at ways to develop reusable classes using atechnique called design-by-contract.Chapter 4: Object Initialization and CleanupThis chapter walks you through the lifecycle of objects from creation to dele-tion. Along the way, you will learn how to interact with this process to maxi-mize performance and improve the integrity of your designs.Chapter 5: InheritanceOne of the potential side effects of good object-oriented designs is the ability toreuse code. In this chapter, you will learn how to reuse classes using the con-cept of inheritance. We will also consider an alternative form of class reuseknown as composition.Chapter 6: PolymorphismThis chapter shows you how to exploit inheritance relationships described inChapter 5 using a technique referred to as polymorphism. This discussion ishighlighted by the introduction of interfaces, which are pure elements ofdesign.Chapter 7: Component-Based Design ConceptsAfter covering the basics of object-oriented programming in Chapters 1–6, thischapter broadens the focus a bit by showing you how the ABAP Package Con-cept can be used to organize your class libraries into coarse-grained develop-ment components.Chapter 8: Error Handling with ExceptionsThis chapter explains how to deal with exceptions in your classes and pro-grams using the ABAP class-based exception handling concept.Chapter 9: Unit Testing with ABAP UnitThis chapter shows you how to develop automated unit tests using the ABAPUnit test framework. These tests help you ensure that your classes deliver onthe functionality described in their API contracts.Chapter 10: Working with the SAP List ViewerThis chapter is the first of three case study chapters that show you how ABAPObjects classes can be used in many common development tasks. In this chap-ter, you see how to create interactive reports using the new object-oriented 17
    • Introduction ALV Object Model. This chapter also provides a practical example for working with events in ABAP Objects. Chapter 11: ABAP Object Services This chapter demonstrates the use of the services provided by the ABAP Object Services framework. In particular, you will learn how to use these services to develop persistent classes whose state can be stored in the database without having to write a single line of SQL. Chapter 12: Working with XML This chapter concludes the case study series by showing you how to work with XML documents using the object-oriented iXML library provided with the SAP NetWeaver Application Server. This discussion also provides you with an opportunity to develop an abstract data type that uses most of the concepts described throughout the course of the book. Chapter 13: Where to Go From Here In this final chapter, we will look ahead to see how to apply the object-oriented concepts learned in this book in real-world projects. Appendix: Debugging Objects In this appendix, we will look at how to use the ABAP Debugger tool to debug object-oriented programs.ConventionsThis book contains many examples demonstrating syntax, functionality, and soon. Therefore, to distinguish these sections, we use a font similar to the one usedin many integrated development environments to improve code readability:CLASS lcl_test DEFINITION. PUBLIC SECTION. ...ENDCLASS.As new syntax concepts are introduced, these statements are highlighted using abold listing font (i.e., the PUBLIC SECTION statement in the preceding code snip-pet).18
    • IntroductionAcknowledgmentsI am a firm believer in the saying “you are what you read.” As such, I am indebtedto so many great authors whose works have planted the seeds from which thisbook took form. I have similarly been fortunate enough to have the opportunityto work with so many talented software development professionals who havetaught me so much. It is my sincere hope that this work represents a small tokenof my appreciation for all of their hard work and dedication to the field.I would like to thank Dr. Stephen Yuan and Dr. Jason Denton for opening myeyes to the world of software engineering. I would also like to thank Russell Sloanat IBM and Colin Norton at SAP America for giving me a chance to spread mywings.Much of the inspiration from this book came during my time working on aproject at Raytheon. A special thanks to the good people there who allowed me toplay “mad scientist” with their development methodology. I am also grateful forthe fresh perspective offered by members of the OneAero development team atLockheed Martin. In particular, I would like to thank Greg Hawkins from SAPAmerica, who graciously offered valuable insight whenever I needed someone tolook at this from a different angle.To my editor, Stefan, thank you so much for your support throughout this pro-cess. I would not have been able to do this without you.To my Dad, and my Mom who still corrects my grammar to this day, thanks foralways being there for me.To my children, Andersen and Paige, thank you for all of your love and support.I will always cherish our writing breaks playing on the floor in my office.To my wife Andrea, I just want to say how much I feel loved and supported byyou. Without your influence on my life, I would not be where I am today. I con-sider myself very fortunate to have met someone as special as you.And finally, to Him who is, and was, and is to come again: Soli Deo Gloria.James WoodPrincipal SAP NetWeaver Software Consultant,Bowdark Consulting, Inc., Flower Mound, TX 19
    • As your understanding of a problem domain matures, so also does your comprehension of the relationships and responsibilities of the classes that are being used to model software systems based on that domain. This chapter begins our discussion of inheritance, which is a key object-oriented concept that can be used to expand and refine your object model to evolve with ever-changing functional requirements.5 InheritanceIn Chapter 3, Encapsulation and Implementation Hiding, we examined how youmight try to construct a reusable code library using procedural design techniques.During our investigation, we observed some of the problems that can make it dif-ficult to reuse these libraries in other environments. In the past, whenever devel-opers encountered these kinds of challenges, they typically either tried toenhance/rework the library to accommodate the new requirements, or they cuttheir losses and salvaged as much of the code as possible by copying and pastingit into new development objects. Unfortunately, neither one of these approachesworks very well in practice: Modifying the code library to handle new requirements threatens the integrity of pre-existing programs using the library because it is possible that errors could be introduced into the system along with the changes. The copy-and-paste approach is less risky initially but ultimately increases the cost of long-term maintenance efforts because redundant code makes the over- all code footprint bigger, often requiring enhancements/bug fixes to be applied in multiple places that can be difficult to locate.The reusability predicaments described here are not unique to procedural pro-gramming. In fact, just because a class has been well encapsulated does not meanthat it is immune to the types of errors that could be introduced wheneverchanges are made to the code. However, there are measures that you can take inyour object-oriented designs to avoid these pitfalls. 127
    • 5 Inheritance In this chapter, we will examine how the concept of inheritance can be used to make copies of a class without disturbing the source class or introducing redun- dant code. You will also learn about another technique called composition that provides a way to reuse classes in situations where inheritance doesn’t make sense. 5.1 Generalization and Specialization One of the most difficult parts of the object-oriented design process is trying to identify the classes that you will need to model a domain, what the relationships between those classes should be, and how objects of those classes will interact with one another at runtime. Even the most knowledgeable object-oriented developers rarely get it all right the first time. Often developers new to Object- Oriented Programming (OOP) are troubled by this, fearing the long-term conse- quences of early design mistakes. Fortunately, the use of good encapsulation and implementation hiding techniques should minimize the “ripple effects” normally associated with changing modularized code. Nevertheless, certain changes force us to look at the problem domain in a whole new way. Here, for instance, you may discover that your original design was not sophisticated enough to handle specialized cases. Frequently, during gap analysis, you may realize that you have either failed to identify certain classes in the domain or that you have defined particular classes too generically. For example, let’s say you take a first pass through a set of requirements for a human resources system. During this analysis process, you discover a need for an Employee class, among others. However, during the implementation cycle of the project, more requirements come out that describe specific functionalities rele- vant for certain types of employees. At this point, you could try and enhance the original Employee class to deal with these added features, but this seems counter- intuitive because it clutters the class with too many responsibilities. On the other hand, abandoning the Employee class altogether in favor of a series of specialized classes (e.g., HourlyEmployee, etc.) leads to the kind of code redundancy issues that you want to avoid. Fortunately, object-oriented languages such as ABAP Objects provide a better and more natural way for dealing with these kinds of problems. 128
    • Generalization and Specialization 5.1The concept of inheritance can be used to extend a class so that you can reusewhat is already developed (and hopefully tested) to expand the class metaphor tobetter fit specialized cases. The newly created class is called a subclass of the orig-inal class; the original class is called the superclass of the newly created class. Asthe name suggests, subclasses inherit components from their superclass. Theserelationships allow you to build a hierarchical inheritance tree with superclassesas parent nodes and subclasses as child nodes (see Figure 5.1). In Chapter 6, Poly-morphism, you will see how members of this inheritance tree can be used inter-changeably, providing for some interesting generic programming options. Employee + getID( ) + getName( ) + getHireDate( ) + calculateWage( ) ... HourlyEmployee CommissionEmployee SalariedEmployee + calculateWage( ) + calculateWage( ) + calculateWage( ) ... ... ...Figure 5.1 Inheritance Hierarchy for EmployeesThe root of every inheritance tree is the predefined empty class OBJECT; thusevery class that we have created so far has implicitly inherited from this class. Todemonstrate how to establish explicit inheritance assignments, let’s consider theexample code shown in Listing 5.1.REPORT zemployee_test.CLASS lcl_employee DEFINITION. PUBLIC SECTION. DATA: id TYPE numc10 READ-ONLY. "Demo Purposes Only!!ENDCLASS. 129
    • 5 Inheritance CLASS lcl_hourly_employee DEFINITION INHERITING FROM lcl_employee. PUBLIC SECTION. METHODS: constructor IMPORTING im_id TYPE numc10 im_wage TYPE bapicurr_d, calculate_wage. PRIVATE SECTION. CONSTANTS: CO_WORKWEEK TYPE i VALUE 40. DATA: hourly_wage TYPE bapicurr_d. ENDCLASS. CLASS lcl_hourly_employee IMPLEMENTATION. METHOD constructor. * Must call the constructor of the superclass first: CALL METHOD super->constructor( ). * Initialize the instance attributes: id = im_id. hourly_wage = im_wage. ENDMETHOD. "constructor METHOD calculate_wage. * Method-Local Data Declarations: DATA: lv_wages TYPE bapicurr_d. "Calculated Wages * Calculate the weekly wages for the employee: lv_wages = CO_WORKWEEK * hourly_wage. WRITE: / Employee #, id. WRITE: / Weekly Wage:, lv_wages. ENDMETHOD. "calculate_wage ENDCLASS. START-OF-SELECTION. * Create an instance of class lcl_salaried_employee * and call method "calculate_wage": DATA: gr_employee TYPE REF TO lcl_hourly_employee. CREATE OBJECT gr_employee 130
    • Generalization and Specialization 5.1 EXPORTING im_id = 1 im_wage = 10.00. CALL METHOD gr_employee->calculate_wage( ).Listing 5.1 Example Report Showing Inheritance SyntaxThe report program ZEMPLOYEE_TEST in Listing 5.1 contains two simple classes:lcl_employee and lcl_hourly_employee. In this example, class lcl_hourly_employee is a subclass of class lcl_employee and therefore inherits its public idattribute. Note that the id attribute is only defined in the PUBLIC SECTION of classlcl_employee for the purposes of this demonstrative example. You will learnabout a better alternative for providing access to sensitive superclass componentsin Section 5.2.1, Designing the Inheritance Interface.The inheritance relationship is specified using the INHERITING FROM addition tothe CLASS DEFINITION statement that was used to define class lcl_hourly_employee. Inside class lcl_hourly_employee, several references are made to theid attribute from the lcl_employee superclass. Here, notice that we didn’t have todo anything special to access this component in the subclass because it has beenautomatically inherited from the superclass.You can define inheritance relationships in global classes by clicking on the Cre-ate Inheritance button on the Create Class dialog box (see Figure 5.2). This addsan additional Superclass input field that can be used to enter the superclass (seeFigure 5.3).You can also maintain the inheritance relationship on the Properties tab of theClass Editor (see Figure 5.4). Here, you can remove the relationship or define anew superclass as well. Inheritance is more than just a fancy way of copyingclasses into new classes. Inheritance defines a natural relationship that will likelyexpand over time.To appreciate the nature of this relationship, let’s consider a situation where youare asked to start keeping track of addresses for employees. Furthermore, let’simagine that you have extended the class hierarchy from Listing 5.1 to includevarious other subclass types. In this case, you need to maintain addresses for allemployees. You could add an address attribute to each of the subclasses, but thatwould be redundant because every type of employee should have an address. Thelogical place to create the address attribute is in the superclass lcl_employee. 131
    • 5 Inheritance Figure 5.2 Defining Inheritance for Global Classes — Part I Figure 5.3 Defining Inheritance for Global Classes — Part II Figure 5.4 Editing Inheritance Relationships for Global Classes 132
    • Inheriting Components 5.2Making the change in the lcl_employee superclass ensures that the addressattribute is automatically inherited by each of the subclasses because of the inher-itance relationship that they maintain with the superclass. However, if you makechanges in the subclasses (e.g., lcl_hourly_employee), these changes are notreflected in the superclass. This functionality allows you to expand your codelibraries with subclasses that do not jeopardize the integrity of their superclassesand the production code that is depending on them.5.2 Inheriting ComponentsSo far, our discussions on the subject of component visibility have focused ondesigning a class’s public and private interface from an external user point-of-view. However, inheritance adds a new dimension into the mix because we nowalso need to consider how to define the interface between a superclass and itssubclasses. Sometimes, you might want to provide access to a component in sub-classes without having to expose the component in the public interface.For example, in Listing 5.1 shown earlier, if the id attribute of class lcl_employeehad been placed in the PRIVATE SECTION of the class, that attribute could not beaddressed inside the lcl_hourly_employee subclass. Therefore, id was exposed asa public, read-only attribute. Of course, good implementation hiding techniqueswould call for exposing access to that private attribute through a getter method,but you get the idea.5.2.1 Designing the Inheritance InterfaceTo address this middle ground, ABAP Objects provides another alternative byallowing you to define components within the PROTECTED SECTION of a class defi-nition.The components defined within the PROTECTED SECTION of a class make up theinterface between a superclass and its subclasses. Subclasses can access compo-nents defined in the PROTECTED SECTION of a superclass in the same way that theywould access components defined in the PUBLIC SECTION of that superclass. To theoutside world however, components defined in the PROTECTED SECTION of a classbehave just like components defined in the PRIVATE SECTION of the class. Listing5.2 redefines the lcl_employee class from Listing 5.1 to use the PROTECTED SEC-TION visibility area. 133
    • 5 Inheritance CLASS lcl_employee DEFINITION. PROTECTED SECTION. DATA: id TYPE numc10, hire_date TYPE sydatum. ENDCLASS. CLASS lcl_hourly_employee DEFINITION INHERITING FROM lcl_employee. PUBLIC SECTION. METHODS: constructor IMPORTING im_id TYPE numc10 im_hire_date TYPE sydatum, display. ENDCLASS. CLASS lcl_hourly_employee IMPLEMENTATION. METHOD constructor. * Must call the constructor of the superclass first: CALL METHOD super->constructor( ). * Initialize the instance attributes; * Notice that we can access these attributes directly: id = im_id. hire_date = im_hire_date. ENDMETHOD. "constructor METHOD display. WRITE: / Employee #, id, was hired on, hire_date. ENDMETHOD. "display ENDCLASS. Listing 5.2 Defining and Accessing Protected Components As you start to design your inheritance interfaces, it is important not to get car- ried away with defining components in the PROTECTED SECTION of the class. Some- times, we tend to think of subclasses as having special privileges that should allow them full access to a superclass. Here, it is essential that you employ the encapsu- lation concept of least privilege when designing your subclasses. The concept of least privilege implies that if a subclass doesn’t really need to access a component, then it shouldn’t be granted access to that component. For 134
    • Inheriting Components 5.2example, imagine that you have defined some superclass that contains certaincomponents that you want to change in some way. If these components aredefined in the protected visibility section of the superclass, it is quite possible thatthese changes cannot be carried out without affecting all of the subclasses thatmay be using these components. The general rule of thumb here is to alwaysdefine attributes in the private visibility section. If a subclass needs to be grantedaccess to these components, then the access should be provided in the form ofgetter/setter methods that are defined in the PROTECTED SECTION of the class. Thislittle bit of additional work ensures that a superclass is fully encapsulated.5.2.2 Visibility of Instance Components in SubclassesSubclasses inherit the instance components of all of the superclasses defined intheir inheritance tree. However, not all of these components are visible at the sub-class level. A useful way of understanding how these visibility rules work is toimagine that you have a special instance attribute pointing to an instance of thesuperclass inside of your subclass. You can use this reference attribute to accesspublic components of the superclass, but access to private components isrestricted just as it would be for any normal object reference variable.As it turns out, this imaginary object reference metaphor is not too far off fromwhat is actually implemented in subclasses behind the scenes. Subclasses containa special pseudo reference variable called super that contains a reference to aninstance of an object of the superclass’s type. This reference is used to access com-ponents of a superclass inside a subclass. The primary difference between thesuper pseudo reference variable and a normal reference variable is that the superpseudo reference can also be used to access components defined in the PROTECTEDSECTION of the superclass it points to.The use of the super pseudo reference variable is optional (as was the case withthe me self-reference variable discussed in Chapter 2, Working with Objects) butcan be used in situations where explicit reference to superclass components isneeded. Normally, you will simply access the components of the superclassdirectly, but it is important to remember that the compiler is implicitly pluggingin the super pseudo reference behind the scenes to properly address these com-ponents. If you operate in this mindset, the visibility rules for accessing super-class components should be pretty intuitive. 135
    • 5 Inheritance Public and protected components of classes in an inheritance tree all belong to the same internal namespace. This implies that you cannot create a component in a subclass using the same name that was used to define a component in a super- class. There is no such restriction on the naming of private components, however. For example, if you define a private component called comp in a superclass, you can reuse this same name to define components in subclasses without restriction. 5.2.3 Visibility of Class Components in Subclasses Subclasses also inherit all of the class components of their superclasses. Of course, as was the case with instance components, only those components that are defined in the public or protected visibility sections of a superclass are actually visible at the subclass level. However, in terms of inheritance, class attributes are not associated with a single class but rather to the overall inheritance tree. The change in scope makes it possible to address these class components by binding the class component selector operator with any of the classes in the inheritance tree. This can be confusing because class components are defined in terms of a given class and probably don’t have a lot of meaning outside of their defining class’s context. To avoid this kind of confusion, it is recommended that you always address class components by applying the class component selector to the defin- ing class’s name (e.g., lcl_superclass=>component). That way, your intentions are always clear. 5.2.4 Redefining Methods Frequently, the implementation of an inherited method needs to be changed at the subclass level to support more specialized functionality. You can redefine a method’s implementation by using the REDEFINITION addition to the method def- inition in your subclass. The code example in Listing 5.3 shows how class lcl_hourly_employee is redefin- ing the default (dummy) implementation of method calculate_wage from the lcl_employee superclass. In Section 5.3.1, Abstract Classes and Methods, we will demonstrate a better approach for defining methods like calculate_wage at a generic superclass level. 136
    • Inheriting Components 5.2CLASS lcl_employee DEFINITION. PROTECTED SECTION. METHODS: calculate_wage RETURNING VALUE(re_wage) TYPE bapicurr_d.ENDCLASS.CLASS lcl_employee IMPLEMENTATION. METHOD calculate_wage.* Empty for now... ENDMETHOD.ENDCLASS.CLASS lcl_hourly_employee DEFINITION INHERITING FROM lcl_employee. PUBLIC SECTION. METHODS: calculate_wage REDEFINITION.ENDCLASS.CLASS lcl_hourly_employee IMPLEMENTATION. METHOD calculate_wage.* re_wage = hours worked * hourly rate... ENDMETHOD.ENDCLASS.Listing 5.3 Redefining Methods in SubclassesTo redefine a method in a global class, place your cursor in the Method columnfor the method that you want to redefine, and click on the Redefine button (seeFigure 5.5).Figure 5.5 Redefining Methods in Global Classes 137
    • 5 Inheritance Whenever you redefine a method, you are only allowed to redefine its implemen- tation — the method interface (or signature) must remain the same. The redefini- tion obscures the superclass’s implementation in the subclass, which means that whenever a call is made to the method for an object of the subclass type, the rede- fined implementation will be used instead. Sometimes, the redefinition simply needs to add on to what was previously implemented in the superclass. In this case, you can use the super pseudo reference to invoke the superclass’s method implementation so that you don’t have to reinvent the wheel. 5.2.5 Instance Constructors Unlike other normal instance components, constructors are not inherited. If you think about it, this makes sense because each class only knows how to initialize objects of its own type. To ensure that the instance attributes of its superclasses are also properly initialized, a subclass is required to explicitly call the constructor of its superclass before it starts to initialize its own instance attributes. This is achieved using the syntax shown in Listing 5.4. Here, the use of parameters is optional depending upon whether or not the constructor of the immediate super- class requires them. CALL METHOD super->constructor [EXPORTING im_param1 = value1 im_param2 = value2 ...]. Listing 5.4 Syntax for Calling the Constructor of a Superclass Whenever you instantiate a subclass using the CREATE OBJECT statement, the ABAP runtime environment will take care of recursively walking up the inherit- ance tree to make sure that the constructor of each superclass is called. At each level in the inheritance hierarchy, a superclass’s constructor will only have visibil- ity to its own components and those defined in its superclasses. This implies that a method call inside the superclass constructor will be bound to the implementa- tion defined for that superclass and not a redefined version defined at the sub- class level. This complex sequence of events is best demonstrated using an example. In List- ing 5.5, the subclass lcl_child redefines the message method that was inherited 138
    • Inheriting Components 5.2from class lcl_parent. As you can see, the message method is called in the con-structors for both classes. However, if you instantiate an object of type lcl_child,you will see that the constructor of the lcl_parent class called its own implemen-tation rather than the redefined version in class lcl_child.CLASS lcl_parent DEFINITION. PUBLIC SECTION. METHODS: constructor, message.ENDCLASS.CLASS lcl_parent IMPLEMENTATION. METHOD constructor. CALL METHOD me->message. ENDMETHOD. "constructor METHOD message. WRITE: / In parent.... ENDMETHOD. "messageENDCLASS.CLASS lcl_child DEFINITION INHERITING FROM lcl_parent. PUBLIC SECTION. METHODS: constructor, message REDEFINITION.ENDCLASS.CLASS lcl_child IMPLEMENTATION. METHOD constructor. CALL METHOD super->constructor. CALL METHOD me->message. ENDMETHOD. "constructor METHOD message. WRITE: / In child.... ENDMETHOD. "messageENDCLASS.Listing 5.5 Example Showing Constructor Call Sequence and Scope 139
    • 5 Inheritance 5.2.6 Class Constructors Each subclass is also allowed to define its own unique class constructor. This con- structor gets called right before the class is addressed in a program for the first time. However, before it is executed, the ABAP runtime environment walks up the inheritance tree to make sure that the class constructor has been called for each superclass in the inheritance hierarchy. These class constructor calls occur in the proper order. For example, let’s imagine that you have a class hierarchy with four classes A, B, C, and D. When a program tries to access class D for the first time, the runtime envi- ronment will first check to see if the class constructors have been called for classes A, B, and C. If the class constructor has already been called for class A, but not for B and C, then the order of class constructor calls will be B, C, and D. This ensures that the class attributes of a superclass are always properly initialized before a subclass is loaded. 5.3 The Abstract and Final Keywords Occasionally, you may identify an occurrence where you need to define a class whose functionality cannot be fully implemented on its own. Such classes must be completed by subclasses that fill in the gaps. 5.3.1 Abstract Classes and Methods A crude way of dealing with these gaps is to create “dummy” methods to com- pletely define the class. However, this can be dangerous because often these methods really don’t make much sense in the context of a generic superclass. In these situations, it is better to define an abstract class that explicitly delegates unknown features to subclasses. Because their implementation is incomplete, abstract classes cannot be instantiated on their own. Their purpose is to provide a common template that makes it easier to implement specialized subclasses. To understand how all this works, let’s revisit the Employee example initially shown in Listing 5.1. There, method calculate_wage was not created at the superclass level but rather at the subclass level (i.e., in class lcl_hourly_ employee). However, if you think about it, this method is really applicable for all types of employees. Of course, at the generic superclass level (i.e., in class 140
    • The Abstract and Final Keywords 5.3lcl_employee), we do not know how to calculate the wages of an employee. Nev-ertheless, as you will see in Chapter 6, Polymorphism, it is advantageous to definethis behavior at the appropriate level in the inheritance hierarchy.The code in Listing 5.6 shows how the class hierarchy has been reworked (orrefactored) by defining lcl_employee as an abstract class. Method calculate_wagehas also been defined as an abstract method inside class lcl_employee. Thesechanges force any subclasses of lcl_employee to either provide an implementa-tion for method calculate_wage or be defined as abstract (thus further propagat-ing the functionality down the inheritance hierarchy). In this case, methodcalculate_wage has been fully implemented in class lcl_hourly_employee.CLASS lcl_employee DEFINITION ABSTRACT. PUBLIC SECTION. METHODS: constructor IMPORTING im_id TYPE numc10, calculate_wage abstract. PROTECTED SECTION. DATA: id TYPE numc10.ENDCLASS.CLASS lcl_employee IMPLEMENTATION. METHOD constructor. id = im_id. ENDMETHOD.ENDCLASS.CLASS lcl_hourly_employee DEFINITION INHERITING FROM lcl_employee. PUBLIC SECTION. METHODS: constructor IMPORTING im_id TYPE numc10 im_wage TYPE bapicurr_d, calculate_wage REDEFINITION. PRIVATE SECTION. CONSTANTS: CO_WORKWEEK TYPE i VALUE 40. DATA: hourly_wage TYPE bapicurr_d.ENDCLASS.CLASS lcl_hourly_employee IMPLEMENTATION. METHOD constructor. 141
    • 5 Inheritance * Must call the constructor of the superclass first: CALL METHOD super->constructor( im_id ). * Initialize the instance attributes: hourly_wage = im_wage. ENDMETHOD. "constructor METHOD calculate_wage. * Local Data Declarations: DATA: lv_wages TYPE bapicurr_d. "Calculated Wages * Calculate the weekly wages for the employee: lv_wages = CO_WORKWEEK * hourly_wage. WRITE: / Employee #, id. WRITE: / Weekly Wage:, lv_wages. ENDMETHOD. "calculate_wage ENDCLASS. Listing 5.6 Defining Abstract Classes and Methods You can create abstract global classes by setting the instantiation type to Abstract on the Properties tab of the Class Editor (see Figure 5.6). Figure 5.6 Creating Abstract Global Classes To create abstract methods for global classes in the Class Editor, place your cursor in the Method column, and click on the Detail View button. This opens up a dia- log box that allows you to modify various attributes for the method. In this case, 142
    • The Abstract and Final Keywords 5.3click the Abstract checkbox. This opens a prompt advising you that the methodimplementation was deleted (see Figure 5.7). Detail View ButtonFigure 5.7 Defining Abstract Methods for Global Classes5.3.2 Final ClassesSometimes, you may refine a class hierarchy to the point where it no longermakes sense to extend it. At this stage, it is best to announce this situation for-mally by marking the class’s inheritance tree as complete using the FINAL modi-fier. Final classes cannot be extended in any way, effectively concluding a branchof an inheritance tree. The syntax for creating final classes is shown in Listing 5.7.CLASS lcl_ender DEFINITION FINAL. ...ENDCLASS.Listing 5.7 Syntax for Defining Final Classes 143
    • 5 Inheritance Global classes are marked as final by selecting the Final checkbox on the Proper- ties tab in the Class Editor (see Figure 5.8). Figure 5.8 Marking Global Classes as Final You should exercise extreme caution when deciding to mark a class as final. Although you may think that you have reached the end of the class hierarchy, it is hard to know for certain. The bottom line is that if you have any doubts about what you are doing, it’s probably best that you don’t do it. 5.3.3 Final Methods A less risky approach to finalizing a class is to mark individual methods as final. This way, you still leave yourself the option for extending the class without allow- ing users of that class to redefine specific methods that you believe to be com- plete. The syntax for defining final methods is shown in Listing 5.8. CLASS lcl_ender DEFINITION. PUBLIC SECTION. METHODS: complete FINAL. ENDCLASS. Listing 5.8 Defining Final Methods You can mark the final indicator for methods in global classes in the same method Detail View screen shown in Figure 5.7. Here, you simply click the Final check- box to mark the method as complete (see Figure 5.9). 144
    • Inheritance Versus Composition 5.4Figure 5.9 Defining Final Methods for Global Classes5.4 Inheritance Versus CompositionDevelopers sometimes get confused by the hype surrounding inheritance, assum-ing that they must make extensive use of it in their designs to be true object-oriented programmers. Note that while inheritance is powerful, it is not alwaysthe best solution for reusing code from existing classes. In fact, one of the worstmistakes you can make is to try to stretch classes to fit into some sort of looselyformed inheritance relationship.Whenever you are thinking of defining a new class in terms of some pre-existingclass, you should ask yourself whether or not the relationship between the sub-class and superclass fits into the is-a relationship mold. To illustrate this, let’s con-sider an inheritance tree for various types of order objects (see Figure 5.10). Ateach level of the tree, you should be able to apply the is-a relationship between asubclass and its superclass, and it should make sense. For example, a SalesOrder isan Order, and so on. 145
    • 5 Inheritance Order Contract SalesOrder SchedulingAgmt CashOrder RushOrder Figure 5.10 Inheritance Tree for Order Types Most of the time, the application of the is-a test should make inheritance relation- ships between classes pretty obvious. For example, if we try to extend the Order class in Figure 5.10 to create a Delivery subclass, the is-a relationship would not make sense (i.e., a Delivery is not an Order). Although this observation should be clear to even the novice developer, it is not uncommon to encounter situations where developers have tried to create inher- itance relationships like this in an effort to leverage classes that have useful fea- tures or similarities to the ones they are trying to implement. Whenever you find yourself stuck trying to figure out ways to define an inheritance relationship between two classes, it is a good idea to take a step back and think about the rela- tionship between the classes from a logical perspective. If you think about it, a Delivery is not an Order, but an Order does have one or more Deliveries associated with it. This has-a association is commonly referred to as a composition relation- ship. The term composition basically describes the reuse of existing functionality in classes by integrating objects of those classes as attributes in your new class. You can use these attributes in the same way that you have used ordinary attributes based on elementary types, structures, and so on. Listing 5.9 shows how you could define a composition relationship between an Order object and a Delivery object. CLASS lcl_delivery DEFINITION. PUBLIC SECTION. METHODS: constructor, 146
    • Inheritance Versus Composition 5.4 get_delivery_date RETURNING value(re_date) TYPE sydatum. PRIVATE SECTION. DATA: delivery_date TYPE sydatum.ENDCLASS.CLASS lcl_delivery IMPLEMENTATION. METHOD constructor. delivery_date = sy-datum. ENDMETHOD. METHOD get_delivery_date. re_date = delivery_date. ENDMETHOD.ENDCLASS.CLASS lcl_order DEFINITION. PUBLIC SECTION. METHODS: constructor IMPORTING im_id TYPE i, release, track. PRIVATE SECTION. DATA: id TYPE i, delivery TYPE REF TO lcl_delivery.ENDCLASS.CLASS lcl_order IMPLEMENTATION. METHOD constructor. id = im_id. ENDMETHOD. "constructor METHOD release.* Arbitrarily create a delivery for the order... CREATE OBJECT delivery. ENDMETHOD. "release METHOD track.* Local Data Declarations: DATA: lv_delivery_date TYPE sydatum. 147
    • 5 Inheritance lv_delivery_date = delivery->get_delivery_date( ). WRITE: / Order #, id, was shipped on, lv_delivery_date. ENDMETHOD. "track ENDCLASS. Listing 5.9 Reusing Classes with Composition You should favor the use of composition over inheritance unless the inheritance relationships between classes are obvious. In Chapter 6, Inheritance, you will see how inheritance can bring along some unwanted baggage that can lead to inflex- ible designs if you are not careful. 5.5 Using the Refactoring Assistant Inheritance provides a natural way for extending classes to adapt to changing functional requirements. However, sometimes you may not discover inheritance relationships until later on in the software development lifecycle. At that point, it is likely that you have not defined classes at the right level of granularity. For instance, let’s revisit the Employee class hierarchy example that we have con- sidered throughout this chapter. In this case, let’s imagine that the initial set of requirements only described functionality related to employees paid by the hour. Based on the information available at the time, you might decide that you simply need to create a single class called HourlyEmployee. At a later stage in the project, you are confronted with new requirements that are related to salaried employees, and so on. At this point, you realize that you probably need to incorporate a more generic Employee class at the root of the inheritance tree. Such changes will cer- tainly affect the internal structure of class HourlyEmployee (although hopefully the use of encapsulation techniques will make these changes transparent to the outside world). In any event, any time you make changes such as this, you run the risk of introducing errors into the system. However, if you ignore these architec- tural observations, the effectiveness of your design will ultimately deteriorate over time. In his famous book Refactoring: Improving the Design of Existing Code (Addison- Wesley, 1999), Martin Fowler describes a process called refactoring that can be used to incorporate these kinds of structural changes into a design. The basic idea here is to improve the underlying structure of a system without affecting its exter- nal behavior. The Refactoring book describes a series of refactorings (or patterns) 148
    • Using the Refactoring Assistant 5.5that can guide you toward making good design decisions whenever you alter thestructure of your classes. In many cases, these refactorings must be performedmanually and therefore require careful attention to detail to ensure that thechanges are propagated consistently throughout the system.Fortunately, SAP has provided a useful tool inside the Class Builder to assist youwith your refactoring efforts for global classes. The Refactoring Assistant tool canbe used to automatically perform some of the most common refactorings. Thisautomation helps to ensure that you don’t accidentally make a mistake by omit-ting some of the manual steps involved with moving components betweenclasses, and so on.To demonstrate the functionality of the Refactoring Assistant tool, let’s try to per-form a Move Method refactoring to move method CALCULATE_WAGE from classZCL_HOURLY_EMPLOYEE to a newly derived superclass called ZCL_EMPLOYEE.1. To start the Refactoring Assistant tool, select Utilities Refactoring Assistant from the top menu bar of the Class Editor screen (see Figure 5.11).Figure 5.11 Opening the Refactoring Assistant Tool2. Inside the Refactoring Assistant tool, you are presented with a tree control con- taining the subclass (ZCL_HOURLY_EMPLOYEE), its components (e.g., CALCULATE_ WAGE), and its superclass (ZCL_EMPLOYEE) as shown in Figure 5.12.3. To move the CALCULATE_WAGE method up to the base class level, select and drag the method name up onto the ZCL_EMPLOYEE node. Click on the Save button in the Refactoring Assistant toolbar to save these changes. At this point, both classes need to be activated for the changes to be fully committed.SAP has plans to expand the functionality of the Refactoring Assistant in futurereleases, promising tighter integration with the new ABAP Editor. These features 149
    • 5 Inheritance will make the process of refactoring even more reliable and efficient, helping to ease the concerns of management types who fail to see the value in “fixing some- thing that isn’t broken.” Figure 5.12 The Refactoring Assistant Editor 5.6 UML Tutorial: Advanced Class Diagrams Part I Section 1.6, UML Tutorial: Class Diagram Basics, introduced some of the basic elements of a class diagram, showing you how to define rudimentary classes along with their attributes and behaviors. In this chapter and the next one, we will expand our discussion of class diagrams to incorporate some of the more advanced concepts that have been described in the past few chapters. 5.6.1 Generalization Most of the time, our discussions on inheritance tend to focus on specializations at the subclass level. However, if you look up the inheritance tree, you see that superclasses become more generalized as you make your way to the top of the tree. Perhaps this is why the creators of the UML decided to describe the notation used to depict inheritance relationships between classes in a class diagram as a generalization relationship. Figure 5.13 shows a basic class diagram that depicts a superclass called Account along with two subclasses (CheckingAccount and SavingsAccount). Notice that each subclass has a connector drawn upward toward their superclass. The triangle at the top of the association identifies the relationship between the two classes as a generalization. 150
    • UML Tutorial: Advanced Class Diagrams Part I 5.6 Account Generalization CheckingAccount SavingsAccountFigure 5.13 UML Class Diagram Notation for Generalizations5.6.2 Dependencies and CompositionIn Section 5.4, Inheritance versus Composition, we described the concept ofinheritance in terms of a has-a relationship between two classes. In Chapter 1,Introduction to Object-Oriented Programming, we looked at how associationscould be used to depict a composition relationship between classes. However, anassociation depicts a fairly loose relationship between two classes. Sometimes,you will want to define a composition relationship in more detail.For example, often a composing class is highly dependent on a supplier class. Inthat case, it is a good idea to depict this tight coupling by creating a dependencyrelationship between the composing class and the supplier class. Figure 5.14shows the dependency relationship between an Order class and a Delivery classas described in Section 5.4, Inheritance versus Composition. Order DeliveryFigure 5.14 Defining a Dependency Relationship Between ClassesThe UML also provides a specific notation for depicting composition relation-ships. In Figure 5.15, this notation is used to show that an instance of classAddress can be embedded inside either class Customer or class Vendor, but notboth. This notation also implies that any instances of class Address will be deletedwhenever the instance of the composing Customer or Vendor class is deleted. 151
    • 5 Inheritance Customer Address Vendor * * Figure 5.15 Defining Composition Relationships in Class Diagrams As you can see in Figure 5.15, the filled-in diamond in the association line between the two classes in a composition relationship is always affixed to the composing class. The direction and cardinality of the association lines further describes the nature of the composition relationship. For example, in Figure 5.15, classes Customer and Vendor can reference zero or more instances of class Address. Looking back at Section 5.4, Inheritance versus Composition, you can see that the UML interpretation for composition relationships is much more specific than the more common view of composition used in normal development scenarios. Con- sequently, you should be careful to only use the UML composition notation whenever you intend for composed objects to be completely managed by their composing objects. 5.6.3 Abstract Classes and Methods Figure 5.16 shows the UML notation for depicting abstract classes and methods. The only requirement here is to italicize the class or method name to indicate that the class or method is to be defined as abstract. Employee + getId( ) + getName( ) + getHireDate( ) + calculateWage( ) HourlyEmployee CommissionEmployee SalariedEmployee + calculateWage( ) + calculateWage( ) + calculateWage( ) Figure 5.16 Defining Abstract Classes and Methods 152
    • Summary 5.7Because italics are sometimes hard to read, you will often see developers tagabstract classes using the << abstract >> keyword (see Figure 5.17). << abstract >> Employee + getId( ) + getName( ) + getHireDate( ) + calculateWage( ) HourlyEmployee CommissionEmployee SalariedEmployee + calculateWage( ) + calculateWage( ) + calculateWage( )Figure 5.17 Non-Normative Form for Defining Abstract Classes5.7 SummaryIn this chapter, you have learned how inheritance and composition techniquescan be used to quickly and safely reuse the implementations of existing classes. Inthis chapter, we concentrated our focus on inheriting a class’s implementation.However, there is another dimension of the inheritance relationship that we havenot yet considered. In the next chapter, you will see how type inheritance can beused to further exploit inheritance relationships to make your designs more flex-ible. 153
    • IndexA Abstract class (cont.) Template 140ABAP Debugger tool 333 Usage scenario 141ABAP Editor Abstract data type 25 Insert Statement wizard 268 Class example 101ABAP List Viewer SAP List Viewer Function group example 94ABAP Object Services 279 lcl_date 67 Persistence Service 281 Reading list ADT 311 Query Service 295 Abstract method 140ABAP Objects 23 in global class 142 Obsolete statement 52 in local class 141ABAP Objects class Addition Declaration part 41 RAISING 215 Implementation part 41 ALV Object Model 257, 260 Syntax overview 41 CL_SALV_EVENTS_TABLE 271ABAP Unit 233 CL_SALV_TABLE 260 ABAP Workbench 236, 245 Event handling 271 Automating test run 245 Example program 261 Code Inspector 245 Overview 260 Controlling test generation 238 Release 257 Creating test class 237 ALV SAP List Viewer Error severity 247 Assertion Evaluating unit test result 246 CL_AUNIT_ASSERT 236 Example 241 Attribute 43 Executing unit test 244 CLASS-DATA keyword 43 Fixture 239 Constant 43 Generating test class for global class 240 CONSTANTS keyword 43 Overview 234 DATA keyword 43 Profile parameter abap/test_generation 238 Defining class attribute 43 Release version 235 Defining instance attribute 43 Result display screen layout 246 Definition example 43 SAUNIT_CLIENT_SETUP 238 Naming 44ABAP visibility section 42, 96 READ-ONLY keyword 98 Global class assignment 96 Automation Controller PRIVATE SECTION 42, 96 Eventing 258 PROTECTED SECTION 42, 96, 133 Function 258 PUBLIC SECTION 42, 96Abstract class 140 B Defining in global class 142 Defining in local class 141 BAPI_FLIGHT_GETLIST function 262 Delegation 140 Business Address Services 50 Problem with dummy method 140 345
    • IndexC Class Builder (cont.) Creating class 72C++ 23 Declaring and using types 80Casting Defining attribute 75 ?TO option 160 Defining class component 74 Basic rule 158 Defining event 79 Casting operator (?=) 160 Defining method 77 Defined 158 Exception Builder view 222 Dynamic type 158 Mapping Assistant 288 Example 156 Object Navigator 71 Implicit narrowing cast example 159 Class component 42, 57 Incompatible type 158 Context 57 Narrowing cast 159 Defined 42 Static type 156 Selector 59 Widening cast 160 Selector operator 59CATCH statement 204 Static component 42 Best practices 208 Usage example 57 INTO addition 208 CLASS DEFINITION statement 42CL_SALV_TABLE ABSTRACT addition 141 Instantiation context 260 CREATE addition 118CL_SALV_TABLE Class DEFERRED addition 100 UML class diagram 260 FINAL addition 143CLASS FOR TESTING addition 237 Keyword 25 INHERITING FROM addition 131Class 25 CLASS IMPLEMENTATION statement 51 Attribute 24 Class pool Comparison to function group 91 Defined 71 Extending 129 Class-based exception handling concept 203 Inheriting component 129 CATCH block 205 Method 24 CLEANUP block 209 OBJECT 129 Exception class 203 Private interface 96 Propagating exception 215 Public interface 96 Propagation rule 219 Syntax overview 41 RAISE EXCEPTION statement 211 Visibility section 27 Scope 205Class agent API System-driven exception 211 Agent class relationship 283 TRY control structure 203 Architecture 282 CLASS-DATA keyword 43 CREATE_PERSISTENT method 295 Classic ABAP Debugger tool 333 GET_PERSISTENT method 295 Debugging object 333 IF_OS_CA_PERSISTENCY interface 286, 296 Fields display mode 333 IF_OS_FACTORY interface 286 Filtering the object display 335 Useful method 285 CLEANUP statement 204Class Builder 71 Call sequence 210 ABAP Workbench 71 Forbidden control statement 210 Class Editor screen 74 Usage example 209346
    • IndexCohesion 27 Data typeComponent 41 Abstract data type 25, 67, 94, 101, 311 Class component 42 Debugging object 333 Declaring 42 Create Exception Object option 338 Defining 42 CREATE OBJECT statement 336 Instance component 42 Displaying and editing attribute 333 Namespace 43 Displaying event and registered handler Visibility 95 method 336Component-based design 183 New ABAP Debugger 340Composition 29, 145 Tracing through method 336 Defined 146 Troubleshooting class-based exception 338 Example 146 Viewing reference assignment 337 Favoring over inheritance 148 Design by contract 28, 102 Forwarding 175 Invariant 103 Has-a relationship 146 Postcondition 103Constant Precondition 103 Naming convention 43 Development class 186 Readability 44 Diamond problem 164 Usage example 59 Document Object Model DOMCONSTANTS keyword 43 DOM 310Constructor 111 Format 310 Call sequence 112 Dynamic object allocation Class constructor 115 Performance costs 107 Guaranteed initialization 112 Dynamic type 156 Initializing class attribute with class construc- tor 115 E Instance constructor 111Coupling Encapsulation 27, 89 Loose coupling 28 Combining data and behavior 94CREATE OBJECT statement 53 Least privilege concept 134 TYPE addition 159 Purpose 95Creating object 107 Event 49 CREATE OBJECT statement 53, 108 Class event declaration syntax 49 Memory management concept 108 CLASS-EVENTS keyword 49 Debugging 336D Event handler method 49 Event handling example 259, 271DATA keyword 43 EVENTS Keyword 49Data object EXPORTING parameter 49 Analogy to remote control 157 Implementing event handler method 271 Conversion 156 Instance EVENT Declaration syntax 49 Dynamic data object 110 Processing behavior 275 Dynamic type 158 RAISE EVENT statement 50, 274 Static type 156 Registering handler method 272DATA statement Sending object 49 TYPE REF TO addition 53 SET HANDLER statement 272 347
    • IndexEvent (cont.) Exception handling (cont.) Triggering 274 Cross-cutting concern 201Event handler method Message table parameter 202 Declaration scope 49 Return code parameter 202 Declaration syntax 49 Strategy 202 Example 273 Exception text 223 Implementing 273 As constants 223 Importing parameter interface 50 Mapping to message ID 227Exception 201 MESSAGE statement support 229 CX_ROOT 219 Text parameter 226 Debugging 338 Viewing in the OTR 224 Defining exception class 219 Extensible Markup Language XML Defining exception in the global class method 218 F Defining exception text 223 Defining global exception class 221 Factory pattern 260 Defining local exception class 221 Final class 143 Exception Builder tool 222 Completing an inheritance tree 143 Exception class type 220 Marking global class as final 144 Exception class with message class 222 Marking local class as final 143 Non-class-based exception 203 Final method 144 RAISE EXCEPTION statement 212 Defining final method in global class 144 Runtime error 205 Defining final method in local class 144 Showing exception details example 206 Friend 99 Unchecked exception 211 Argument against 100Exception class Defining relationship 99 Class hierarchy 219 Example 99 Customer namespace 222 Relationship behavior 100 CX_AI_APPLICATION_FAULT 216 Syntax 99 CX_AI_SYSTEM_FAULT 216 Function group 91 CX_DYNAMIC_CHECK 219, 220 Example 91 CX_NO_CHECK 219, 221 Function module 91 CX_STATIC_CHECK 219, 220 Global data 91 CX_SY_ARITHMETIC_ERROR 208 Limitation 91 CX_SY_ARITHMETIC_OVERFLOW 208 Stateless function module 91 CX_SY_FILE_IO 226 Function module CX_SY_MOVE_CAST_ERROR 205 SDIXML_DOM_TO_SCREEN 323 CX_SY_ZERODIVIDE 208 Functional method 47 Global exception class 226 CALL METHOD statement 61 Local exception class 221 CASE statement 64 PREVIOUS attribute 216 COMPUTE statement 64 Standard exception type 206, 211 Creating expression 61 Superclass CX_ROOT 205 Declaration syntax 47 With Message Class option 227 DELETE statement 64Exception handling Expression 63 Ad-Hoc exception handling example 201 IMPORTING parameter syntax 63348
    • IndexFunctional method (cont.) Inheritance (cont.) Logical expression 64 Class component in subclass 136 LOOP statement 64 Class component scope 136 MODIFY statement 64 Class constructor behavior 140 MOVE statement 63 Comparison with composition 145 Operand 61 Component namespace 136 Syntax example 63 Copy-and-paste approach 131 Usage example 61 Defining relationship in global class 131 Defining relationship in local class 129G Defining the inheritance interface 133 Diamond problem 164Garbage collection 121 Eliminating redundant code 127 ABAP runtime environment 121 Final class 140 CLEAR statement 121 Generalization and specialization 128 Destructor method 122 Implementation inheritance 155Global class 41 Instance component in subclass 135 Class pool 41 Instance constructor behavior 138 Defining read-only attribute 98 Interface example 133 Definition section 82 Interface inheritance 155 Direct type entry 81 Interface inheritance versus implementation Local inner class definition 81 inheritance 164 Method implementation 78 Is-a relationship 31 Naming convention 72 Is-a versus has-a relationship 145 Only Modeled option 74 Multiple inheritance 164 Public interface inheritance 155H Redefining method 136 Relationship behavior 131HTML 304 Single inheritance 164 Subclass 30, 129I Super pseudo reference 135 Superclass 30, 129IF statement Superclass method implementation 138 IS SUPPLIED option 119 Tree example 129IF_MESSAGE interface 220 Insert Statement wizard 268IF_SERIALIZABLE_OBJECT interface 220 ABAP Objects pattern 268IF_T100_MESSAGE interface 227 Statement pattern 269Implementation hiding 27, 89 Instance component 42, 54 Approach 95 Defined 42 Example 101 Object component selector operator 55 Getter method 98 Instantiation context 117 Hiding data 97 CREATE addition 118 Responding to change 102 Creational class method 119 Setter method 97 Defining 118Inheritance 30, 127 Defining for global class 118 Abstract class 140 Option 118 Basic example 129 Pattern example 119 349
    • IndexInteraction frame 300 iXML library (cont.) alt Operator 300 IF_IXML_DOCUMENT interface 312 common operator 300 IF_IXML_ELEMENT interface 312 Example 300 IF_IXML_ISTREAM interface 311 Guard 300 IF_IXML_PARSE_ERROR interface 323 loop Operator 300 IF_IXML_PARSER interface 311, 323 Notation 300 IF_IXML_RENDERER interface 319 Operator 300 Interface 311 opt Operator 300 Release 310 par Operator 300 Usage example 311 ref Operator 301 sd Operator 301 JInterface 26, 163 Contract of a class 177 Java 23 Defining a local interface 165 Defining alias name 178 K Defining component 165 Defining global interface 165 Keyword Defining in ABAP Objects 165 CLASS 25 Elementary interface 165 CLASS-DATA 43 Generic basic definition 163 CONSTANTS 43 IF_MESSAGE 220 DATA 43 IF_SERIALIZABLE_OBJECT 220 IF_T100_MESSAGE 227 L Implementing in a global class 168 Implementing in a local class 167 Local class 41 Implementing in class 167 INCLUDE program 70 Interface component selector operator 169 Including in program 64 INTERFACES keyword 167 Visibility 70 Nesting interface 177 Local variable Public visibility section 165 Hiding attribute 52 Scope 165 Naming 52 Syntax 165 Usage 52 Using interface 170 Loose coupling 28Interface reference variable 174 Casting example 174 M Using references polymorphically 174Is-a relationship 31 Mapping Assistant 288Iterator 175 Assignment type 290 CL_SWF_UTL_ITERATOR 175 Business Key assignment type 290iXML library 303 Class Identifier assignment type 290 Architecture of API 311 GUID assignment type 290 CL_IXML factory class 311 Object Reference assignment type 290 DOM-based XML document 311 Tables/Fields display 289 Feature 310 Value Attribute assignment type 290 IF_IXML interface 311350
    • IndexMarkup language 304 N Element 304 Tag 304 Narrowing castMeta-markup language Definition 159 Definition 304 Implicit cast for importing parameter 162Method 45 Nested interface 177 ABSTRACT addition 141 Alias name 178 Boolean 62 ALIASES statement 178 CALL METHOD statement 56 Component interface 177 CHANGING parameter 45 Component scope 178 Class method declaration syntax 48 Defining alias in local interface 178 CLASS-METHODS keyword 48 Defining component interface in global inter- Declaration example 47 face 178 DEFAULT addition 48 Defining component interface in local interface Defining parameter 45 178 EXCEPTIONS addition 203 INTERFACES statement 178 EXPORTING parameter 45 New ABAP Debugger tool 333 FOR TESTING addition 239 Displaying inheritance hierarchy 342 Functional method 47 Layout 340 Implementing 51 Release 333 IMPORTING parameter 45 Nonclass-based exception Instance method declaration syntax 45 Example 217 Method signature 46 METHOD...ENDMETHOD statement 51 O METHODS Keyword 45 Naming convention 48 Object 24, 41 OPTIONAL addition 47 Autonomy 94 Parameter 45 CREATE OBJECT statement 53 RAISING addition 215 Debugging 333 Redefining 136 Dynamic allocation 107 Redefining method in global class 137 Header data 110 Redefining method in local class 136 Identity 94 REDEFINITION addition 136 Initialization and cleanup 107 RETURNING parameter 47 Object instance 26 Using local variable 52 Object lifecycle 107Method signature Performance tuning 122 Defined 46 Self-reference (me) 56Model-View-Controller MVC SWF_UTL_OBJECT_TAB table type 171MVC 261 OBJECT class 129 ABAP reports 266 Object component selector 55 Controller 262 Usage example 55 Coupling 270 Object instance 26 Data binding 264 Object reference assignment Model 262 Assignment operator (=) 53 Report 262 Illustrated example 53 View 262 MOVE statement 53 351
    • IndexObject reference variable 26, 52 Package Builder (cont.) Advanced assignment 155 Object Navigator 189 Assignment 53 Package Interfaces tab 192 Assignment between families of related types Packages Included tab 191 156 Transaction 188 Compatible type 156 Package check tool 196 Declaration context 53 ABAP Workbench 196 Declaration syntax 53 Package concept 185 Defined 52 Creating use access 194 Pointing to object 110 Defining package interface 192 Relationship to object 54 Definition 186 Self-reference (me) 56 Design tip 196 Super pseudo reference variable 135 Embedding package 191Object-Oriented Analysis and Design Main package 186, 187 OOAD Package Builder 188Object-oriented programming OOP Package check 195Object-relational mapping 280 Package versus development class 185 Benefit 280 Release version 185 Concept 280 SAP Application Hierarchy 190 Tool 280 Structure package 186Online Text Repository OTR Sub-package 186, 188OOAD 33, 275 Parameter 45 Defining class relationship 128 Actual parameter 46 Delegating responsibilities to objects 107 CHANGING 45 Domain modeling 128 Default behavior 46OOP 23 EXPORTING 45 Emphasis on data and behavior 94 Formal parameter 46OSREFTAB table type 296 IMPORTING 45OTR 223 Pass-by-reference 46 Pass-by-value 46P RETURNING 47 Syntax 45Package Performance tuning 122 Assignment to SAP Application Hierarchy Class attribute usage 124 190 Design consideration 123 Assignment to software component 190 Lazy initialization 123 Common closure principle 196 Reusing object 124 Common reuse principle 196 Persistence mapping 284 Local Object 66 By business key 284 Package type 190 By instance-GUID 284 Static dependency principle 196 Example 288Package Builder Mapping Assistant 288 Adding package 191 Multiple-table mapping 285 Defining a package interface 192 Single-table mapping 285 Defining use access 194 Strategy 284 Editing a package interface 193 Structure mapping 285352
    • IndexPersistence Service Procedural programming (cont.) Architecture 281 Structured programming 90 CX_OS_OBJECT_EXISTING 295 Tight coupling with main program 90 Deleting persistent object 298 Layered agent class approach 283 Q Managed object 282 Managing persistent object 281 Query Service 295 Mapping concept 284 CL_OS_SYSTEM 296 Mapping strategy 284 Filter 296 Overview 280 IF_OS_QUERY interface 295 Persistent class 282 Logical expression query 295 Updating persistent object 297 Query Manager 296Persistent class 279 Results ordering 296 Agent class 282 Usage example 296 Architecture 282 Building a persistence layer 281 R Class agent API 285 Class Builder 287, 292 RAISE EVENT statement 50, 274 Defining 286 Parameter usage 275 IF_OS_STATE interface 287 Syntax 274 Mapping to a persistence model 280 RAISE EXCEPTION statement 212 Object reference 292 Behavior 213Persistent object 279 Exception object 213 COMMIT WORK statement 295 Syntax 212 Creating new instance 294 Usage example 213 Deletion example 298 RAISING addition Managed object 282 Syntax 215 Transient object 280 Usage example 215 Updating example 297 Reading list ADT 312 Working with 293 Basic structure 314Pointer 110 CL_GUI_FRONTEND_SERVICES 319 Defined 110 Class constructor method 315Polymorphism 31, 155 Example program ZIXMLREADER 324 Dynamic method call binding 160 Example program ZIXMLWRITER 319 Example 160 Method add_book 316 Extensibility 163 Method create_from_file 321 Flexibility 163 Method create_new_list 314Procedural programming 89 Method display 323 ABAP example 91 Method serialize 317 Comparison to OOP 94 New XML document 314 Data support 94 Private instantiation context 312 Functional decomposition 90 XML document 320 Limitation 90 Refactoring 148 Procedure 90 Example 148 Reuse 127 Move method example 149 Step-wise refinement 90 353
    • IndexRefactoring assistant 149 SAP Control Framework (cont.) Accessing 149 Sun JavaBeans control 258 Example 149 User-defined control 260 Expansion 149 SAP flight data model 262Reference parameter SAP List Viewer 257 Defined 46 Field catalog 260 Example 46 SAP NetWeaver Application ServerReference variable 26 ABAP instance 108Regular expression 82 ABAP runtime environment 107 CL_ABAP_MATCHER 82 Extended memory 110 CL_ABAP_REGEX 82 Internal session 109 Defined 82 Main session 109 Example 83 Memory architecture 108 Literal character 82 Multiplexing work process 109 Metacharacter 82 Performance optimization 111 Search pattern 82 Program call stack 109 Selection screen input 83 Roll buffer 108 Telephone number example 83 Shared memory 108Reuse 29 User session 108Reuse Library 257 Work process 108 REUSE_ALV_GRID_DISPLAY 257 SAX 310 SDIXML_DOM_TO_SCREEN function moduleS 323 Self-reference variable 56SAP component model 183 SET HANDLER statement 272 Hierarchy 183 SGML 303 Package 183 Simple API for XML SAX Product 183 Singleton design pattern 282 Software component 183 Implemented in persistent class 282SAP Control Framework Software component ABAP Objects control framework 258 HOME 184 ALV grid control 259 Installed component 184 Architecture 258 LOCAL 184 Automation controller 258 Version 184 Automation queue 258 Software framework 279 Basis release 258 ABAP Object Services 279 Calendar control 260 Sorting CL_GUI_CONTROL 258 Insertion sort algorithm 173 Custom container 259 Standard Generalized Markup Language Custom control 258 SGML Distributed processing 258 Statement HTML viewer control 260 CATCH 204, 208 Microsoft ActiveX control 258 CLASS DEFINITION 42, 100, 118, 131, 141, Overview 257 143, 237 Proxy class 258 CLASS IMPLEMENTATION 51354
    • IndexStatement (cont.) U CLEANUP 204, 209, 210 CREATE OBJECT 53, 159 UML 34 DATA 53 UML activity diagram 229 IF 119 Action 229 RAISE EVENT 50, 274, 275 Activity final node 229 RAISE EXCEPTION 212, 213 Decision node 327 SET HANDLER 272 Decision node guard 327 TRY 203, 204, 205, 208 Expansion region 231 TYPE-POOLS 50 Fork 327Static type 156 Handler block 230 Initial node 229T Join 327 Merge node 230Test class Notation 229 Attribute 238 Partition 325 Basic form 237 Protected node 230 CL_AUNIT_ASSERT 239 Signal 326 Creating 237 Sub-activity 326 Defining fixture method 239 Time signal 327 Defining test method 239 UML class diagram 34 Duration attribute 238 Abstract class and method notation 152 Example 241 Association 38 Risk_Level attribute 238 Attribute notation 36Test-driven development 247 Class notation 35Transaction Composition notation 151 SAUNIT_CLIENT_SETUP 238 Dependency notation 151 SE24 71 Depicting nested and component interfaceTRY statement 180 CATCH block 204 Generalization notation 150 CATCH block organization 208 Generalization notation for interface 180 CATCH statement selection process 205 Interface notation 180 CLEANUP block 204 Non-normative notation for abstract class Control flow 204 153 Defined 204 Notation for relationship with interface 181 Syntax 203 Notation for static attribute and method 182Type 50 Operation notation 37 Naming convention 50 UML communication diagram 275 Scope 50 Collaboration diagram 276 TYPES statement 50 Ease of use 277 Usage 50 Interaction diagram 276 Usage example 50 Notation 276TYPE-POOLS statement 50 Numbering scheme 277 UML communication diagrams Object diagram 277 355
    • IndexUML diagram 34 Unit testing (cont.) Behavioral diagram 103 Informal testing process 234 Cardinality notation 39 Problem with ad hoc test 234 Interaction diagram 105 Scope 233UML diagram (cont.) Terminology 235 Note 39 Test class 236UML object diagram 84 Test method 236 Defined 84 Test run 236 Notation 86 Test task 236 Object box notation 85 Test-driven development 247UML package diagram 197 Unit testing framework 234 Defining visibility of component 197 Validating API contract 233 Dependency notation 197 White box test 235 Notation 197 Unit testing framework 234 Package 197 ABAP Unit 235 Relaxed notation 197 Automated testing 235UML sequence diagram 103 JUnit 235 Deleting an object lifeline 299 NUnit 235 Found message 104 SUnit 235 Interaction frame 300 xUnit 235 Message 104, 105 Use case 248 New message 298 Actor 248, 249 Notation 104 Defined 248 Object activation bar 105 Extension 248 Object lifeline 105 Extension scenario 249 Return message 105 Guarantee 249 Self call 105 Identifying test case 252UML state machine diagram 125 Main success scenario 248, 249 Final state 126 Precondition 249 Initial pseudostate 125 Primary actor 249 Notation 125 Requirements verification 252 State 125 Scope 249 Transition 125 Terminology 249 Transition label syntax 125UML use case diagram 248 V Notation 251 Usage 251 Value parameterUnified Modeling Language UML Defined 46Unit testing 233 Example 46 ABAP Unit 233 Vector 171 Assertion 236 Defining an iterator 175 Black box test 234 Global class ZCL_VECTOR 171 Fixture 236 Usage example 176 IEEE definition 233356
    • IndexW XML (cont.) Semantic 307W3C 303 Syntax overview 305Web Dynpro Web service 328 Screen programming 257 XSLT 328Widening cast XML attribute 307 Compiler check 160 XML document Danger of using 160 Comment syntax 306 Definition 160 Declaration statement syntax 306World Wide Web Consortium W3C DTD 308 Root element 305X Tree structure 307 Validity 308XML 303 Well-formed 307 Attribute syntax 307 XML Schema 308 Case sensitivity 307 XML element 305 Data modeling 305 Nesting 305 Element syntax 305 XML parser 309 Empty element syntax 305 DOM processing model 310 Format 305 Function 310 Markup convention 307 SAX processing model 310 Meta-markup language 304 XML Schema 308 Openness 305 Constraint 308 Overview 303 Standard 308 Parser 309 Processing concept 309 Z Purpose 304 Self-describing document 305 ZIF_COMPARABLE Interface 165 357