Object-Oriented Programming with ABAP Objects

James Wood, Joseph Rupert

• Publisher: SAP PRESS
• Year: 2015
• ISBN:
  9781592299942
• Edition: 2
• Topic: Informatique
• Subtopic: Sciences générales de l'informatique

Part I

Introduction

This chapter provides an overview of object-oriented programming from a conceptual point of view. The concepts described in this chapter lay the foundation for the remainder of the book.

1Introduction to Object-Oriented Programming

Object-oriented programming (OOP) is a programming paradigm in which developers approach program design by modeling solutions in terms of a series of objects that simulate real-world entities from the problem domain. This shift in design philosophy helps us achieve program designs which more closely resemble the world around them. As a result, object-oriented designs tend to be easier to understand, maintain, and extend. The purpose of this chapter is to introduce you to the basic concepts you’ll need to understand in order to effectively design and develop object-oriented programs. These concepts generally apply to most modern OOP languages such as C++, Java, and, of course, ABAP Objects. This chapter will also begin an introduction to the Unified Modeling Language (UML), which is the de facto object modeling language used in the software industry today.

1.1The Need for a Better Abstraction

In the field of software engineering, few topics incite more controversy than object-oriented programming. Loyalists defend the merits of OOP with near religious fervor, while detractors often roll their eyes at the very thought of it. If you’re reading this book, it’s likely that you find yourself somewhere in the middle of this seemingly endless debate. And if that’s the case, probably the most pressing questions on your mind include the following:

• Why should I bother learning OOP?
• Is OOP really better than procedural programming or other methodologies?
• What is it about OOP that makes it so special?

In the sections and chapters to follow, we will attempt to answer these questions by demonstrating how OOP sets itself apart from other programming methodologies by providing a better and more intuitive form of abstraction.

1.1.1The Evolution of Programming Languages

The quality of a language (spoken or otherwise) is generally measured by its effectiveness in expressing complex thoughts and ideas. If we evaluate programming languages using this criterion, we can easily chart the progression from low-level programming languages such as assembly language to higher-level procedural programming languages such as C (and to some extent ABAP). As programming languages evolve, they become easier to read and write with. Of course, this begs the question: what makes a programming language more expressive?

Though there are many schools of thought here (hence the vast number of programming languages in circulation today), each of the approaches taken over the years shares a common goal: to improve the quality and nature of the abstraction(s) that developers have to work with. If we can improve on that, then developer productivity should undoubtedly increase as well.

To put this into perspective, let’s briefly consider the innovations that the C programming language brought to the table back in the days when assembly language programming reigned supreme. In those days, programmers were implementing their designs by twiddling bits of data, manipulating various CPU registers, and so on. With the advent of C, the developer’s palette expanded to include:

• Variables with meaningful names and intuitive data types (e.g. integers and strings of characters)
• Conditional statements that made it possible to encode program logic using statements that more closely resembled spoken language.
• Callable functions that allowed developers to break down complex problems into modules that were easier to understand individually.

With these new abstractions in hand, developers were freed from worrying so much about low-level technical details and could focus more on program logic issues.

Despite these early innovations, by the time the 1960s rolled around language researchers had begun to observe a fundamental truth: The abstractions provided by programming languages up to that point still required developers to think about their solutions “in terms of the structure of the computer rather than the structure of the problem they’re trying to solve,” as Bruce Eckel states in Thinking in C++. This is to say that solutions in code bore little resemblance to the problem domain from which they were conceived. For the purposes of this book, we’ll refer to this phenomenon as semantic dissonance.

The upshot of this trend is that a tremendous burden was placed on developers to ensure that software requirements were accurately translated into program code. And, if one of those requirements got lost in the translation or the developer made a mistake somewhere along the way? Well, let’s just say that it was going to be a rough couple of days for that developer.

1.1.2Moving Towards Objects

Around the time software researchers began to wrap their heads around the semantic dissonance problem, several influential language designers took a collective step back and began contemplating what the most ideal type of abstraction would be. Think of it this way: If you could choose any kind of element to model your program designs, what would you ask for? Would you stop at abstract data types (ADTs) and functions/subroutines? What if instead someone offered you a series of magical objects that look and behave like the entities you interact with in the real world?

While the latter approach may sound too good to be true, it turns out that conjuring up such objects in programs is actually achievable if we begin to think about our program designs just a little bit differently. We’ll have an opportunity to explore this thought process in depth beginning in Section 1.2, but before we segue into more practical matters, let’s take a moment to understand the why in OOP.

At the end of the day, OOP is all about bridging the gap between whatever problem domain we’re working with and the solution space where our program code lives and operates. The goal is to model our code in such a way that it resembles (or simulates) the problem space we’re working in (e.g. purchasing, accounting, and so on). In his book, Thinking in C++, Bruce Eckel summarizes the benefits of this approach: “Casting the solution in the same terms as the problem is tremendously beneficial because you don’t need a lot of intermediate models to get from a description of the problem to the description of the solution.”

Once you begin to see the world through OO glasses, you open yourself up to all kinds of new and exciting possibilities. For example, with objects, it’s easier to achieve reuse because you’re dealing with self-contained entities that have defined responsibilities as opposed to a scattering of data structures and subroutines. This will all become clearer as we progress through the book, but for now, we would simply ask that you open your mind to the possibility of a system overrun by lots of tiny little objects.

1.2Classes and Objects

Students learning pure object-oriented languages like Java are often taught that “everything is an object”. While this is not necessarily the case in a hybrid language like ABAP Objects (where it’s still possible to use procedural constructs), it’s still a good way to start thinking about how to design programs using an object-oriented approach. Of course, it helps if you know what an object is. In this section, we’ll attempt to unravel the mysteries surrounding objects and also consider a closely related concept in OOP: classes.

1.2.1What Are Objects?

From a technical perspective, an object is a special kind of variable that has distinct characteristics and behaviors. The characteristics (or attributes) of an object are used to describe the state of an object. For example a Car object might have attributes to capture information such as the color of the car, its make and model, or even its current driving speed. Behaviors (or methods) represent the actions performed by an object. In our Car example, there might be methods that can be used to drive, turn, and stop the car, for instance.

With all this in mind, our initial definition of an object would read something like this: “An object is a variable that combines data and behaviors together in a self-contained package.” However, if we were to leave off here, our definition would be rather limiting. In his ...

Table of contents

• Dear Reader
• Notes on Usage
• Table of Contents
•   Introduction
•   Structure of the Book
•   Conventions
•   Source Code and Examples
•   Acknowledgments
• Part I – Introduction
• 1   Introduction to Object-Oriented Programming
• 2   Getting Started with Objects
• 3   Encapsulation and Implementation Hiding
• 4   Object Initialization and Cleanup
• 5   Inheritance and Composition
• 6   Polymorphism
• 7   Component-Based Design Concepts
• 8   Error Handling with Exception Classes
• 9   Unit Tests with ABAP Unit
• Part II – Case Studies
• 10   ABAP Object Services
• 11   Business Object Development with the BOPF
• 12   Working with the SAP List Viewer
• 13   Where to Go From Here
• A   Installing the Eclipse IDE
• B   Debugging Objects
• C   Bibliography
• D   The Authors
• Index
• Service Pages
• Legal Notes