Where We Are Now

If you are like many other programmers using SAP, you gained your experience with ABAP before SAP introduced object-oriented features into the ABAP language, or if these features had been introduced, your organization was not using a release where they were available to you. Some of you are former (perhaps even current) COBOL programmers. Regardless of how you found your way to ABAP, chances are you have been using only the “procedural” style of programming and have been very successful at it for years. SAP now refers to this as the “classical” ABAP programming style .

With classical ABAP programming, we may have learned many bad habits, ones that are no longer tolerated with the object-oriented language features. However, because SAP has maintained backward compatibility with the ABAP compiler, there has never been a requirement for ABAP programmers to begin using the object-oriented paradigm. As a consequence, we have been happily sticking with the classical ABAP programming style for years now, shunning the newfangled object-oriented features because 1) it would take some time and effort to learn them and 2) once we began using these features, the compiler would flag our use of those bad habits we had honed so carefully over the years.

SAP now provides a fork in the road regarding ABAP programming style. There are two different sets of ABAP language features available, one facilitating the classic procedural style we have been using for years, and another facilitating the object-oriented paradigm. Although they are mostly compatible, there are some restrictions. We could continue using classical ABAP and perhaps be successful with it for quite a while into the future. Conversely, we could bite the bullet and learn what we can about the object-oriented features and begin to use those.

One thing to consider when pondering this choice is that each new release of SAP contains more and more vendor ABAP code that makes use of the object-oriented features. Prior to using ABAP, we might have worked with an Enterprise Resource Planning (ERP) package where seldom, if ever, would we see vendor source code, regardless of the original language. But as ABAP programmers, it is commonplace to browse the source code of ABAP components supplied by SAP with the standard ERP release. The more this standard SAP code is written using the object-oriented style, the more reason we have to learn and understand it.

However, becoming familiar with the syntax associated with the implementation of object-oriented features into the ABAP language is only one of the hurdles we must overcome. An even larger hurdle is understanding the fundamental concepts of object-oriented programming.

So here is where we find ourselves: capable classical ABAP developers, knowing very little about the new object-oriented ABAP statements and knowing even less about how to use those statements effectively. It should come as no surprise that many ABAP programmers contemplating this challenge will choose to continue on with their classical style and avoid the object-oriented features so long as the ABAP compiler enables them to do so. However, other ABAP programmers, who appreciate the significance of these new changes, who have become enlightened to the benefits of object-oriented programming, and who want to leverage these new capabilities, will undertake to embrace this new paradigm and use it to their full advantage.

Where We Are Going

Object-oriented programming languages have been in existence since the 1960s when Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center introduced the language named Simula I and its successor, Simula 67.¹ Since then, object-oriented concepts have provided the foundation for such languages as Smalltalk, C++, and Java. Other languages initially based on the procedural model have been extended to provide some object-oriented capabilities. ABAP falls into this latter category.

In our quest to reach this district known as object-oriented design, we are headed for a place that was founded over half a century ago and has since grown into a thriving metropolis within the data processing landscape, so it is hardly new. However, it is new to us. This is a place where we can use these object-oriented programming techniques in our ABAP programming efforts as freely and comfortably as the procedural style of coding ABAP has provided since its inception.

Why We Are Going There

Statistics show that the initial development effort of writing a computer program consumes only a small fraction of the total time spent during its life cycle, and that most of the time we devote to programming is in pursuit of maintenance efforts – change.² A significant reason offered by many experts for using the object-oriented programming paradigm is that it is much better than procedural programming at facilitating maintenance efforts. According to Scott Ambler, reusability is one of the great promises of object-oriented technology.³ Simplifying program maintenance is a central theme with object-oriented design and one that is interwoven throughout this book. Also, as noted, each new release of SAP contains more and more object-oriented code, and it is in our best interest to become familiar with this new paradigm so we can more easily understand how the system works, where and how we might place enhancements into the standard SAP code, and how we might begin to make effective use of the vast SAP-supplied global class repository. Although we could continue to ignore this new way of writing code for some time and still experience successes in our programming efforts, we do so at our peril.

How We Are Going to Get There

We are going to start where we are most comfortable and familiar, and then move slowly and methodically until we have mastered the fundamentals of object-oriented programming. This means we will start from the familiar surroundings in our home town of Procedureton and travel along the path of least resistance to our destination of Objectropolis.

Along the way from Procedureton to Objectropolis we will pass through the following districts:

• Encapsulation

• Abstraction

• Inheritance

• Polymorphism

• Interfaces

Each district will present its own unique landscape distinguishing it from the other districts. Although we will use this book primarily to provide the directions for navigating the new terrain, we will also take the opportunity to pause in each district long enough to become more familiar with the new concepts we will encounter by performing exercises designed to strengthen our grasp of the nuances and idiosyncrasies each district has to offer. In the same way that merely reading a book about swimming could not sufficiently prepare us for the experience of actually jumping into the water for the first time, merely reading this book without performing the accompanying exercises would leave us less than sufficiently prepared for the experience of actually using what we will be learning.

The first district we will encounter along the road to Objectropolis is Encapsulation , where the residents excel at organizing components in a way that reduces repetition and conceals those details we don’t need to see. This is first because we already have some familiarity with this concept from procedural programming.

Farther down the road we will move through Abstraction , where the residents have mastered the art of describing the aspects of an entity and assigning a level of detail to components. They are also experts at instantiation, a technique used to make copies of things but where each copy has it own unique attribute values. We also will see how Abstraction and Encapsulation are related to each other.

After Abstraction we will cross into Inheritance , a place where members of the same family tree exhibit similar attributes and behaviors. In some cases, the parents in this district perform many tasks on behalf of their children; in other cases, the children are offered guidance for how to perform tasks themselves; and in still other cases, the children decide they know better than their parents how to perform some tasks and insist on doing things their own way.

Beyond Inheritance lies Polymorphism , where the residents exhibit multiple personalities, behaving differently from one moment to the next depending on how they are type-cast.

Finally, we will traverse through Interfaces , where the residents excel at developing standardized processes for communicating and exchanging information.

Upon passing through all these districts and reaching the end of the road, we will have arrived in Objectropolis, where we will stick our toe into the vast sea known as Unified Modeling Language (UML) from which we will learn some map-making skills, enabling us to orient ourselves as we continue to travel further into the inner sanctum of object-oriented design.

Eventually, we will leave the constraints inherent in the roads we had thus traveled and venture out beyond the stars, exploring the galaxy known as Design Patterns,⁴ the center of which is an inferno providing the nuclear fusion for blending the concepts of Encapsulation , Abstraction , Inheritance , Polymorphism , and Interfaces into robust solutions to our programming challenges. So, buckle up as we embark on a celestial journey throughout the universe known as Object-Oriented Design.

Flip Turns

As a college undergraduate I was a member of the swimming team and specialized in the backstroke. For me, the primary event at a swim meet was the 200-yard backstroke, which required the swimmer to swim eight laps of a 25-yard pool. This entailed touching the wall of the pool and turning after seven of those eight laps. The most efficient way to make the turn is to use a technique known to swimmers as a flip-turn, whereupon, for the backstroke event, in touching the wall with the hand, the swimmer uses the leverage of the hand on the wall to flip backward, in a crouching position until upside down, twisting in mid-flip, throwing both feet against the wall, and then pushing off the wall in the other direction as quickly as possible. I finally mastered this early in my first year on the team.

During that first year I had reached a plateau with my event times. The coach took me aside and explained that he thought he could help. The conversation went something like this:

• “Jim, I think I know why your times are not improving. During your approach for a turn, you always reach for the wall with your right hand. Are you aware of that?”

• “Yes,” I replied, “I always touch the wall with my right hand. It is the only way I am able to perform a flip turn.”

• “You are losing precious time in those instances where your stroke cadence would not put your right hand on the wall when you arrive there, forcing you either to take a quick short stroke or to delay taking a stroke at all. You need to learn to perform a flip turn left-handed so you can turn with whichever hand is about to touch the wall. This will improve your times.”

I worked on this for several weeks. At first it felt uncomfortable because of my proclivity to twist to the right upon touching the wall. I had to do this slowly so I could unlearn the automatic reflex to twist right and to get the feel of making the twist dependent on whichever hand was touching the wall.

Eventually I was able to perform the flip turn with either hand. My times began to improve noticeably because I was no longer handicapping myself to insure touching the wall right-handed. Indeed, much to my surprise, by the end of that first season I found that performing the turns left-handed had become my preference.

As with flip turns in swimming, we want to have the ability to flip comfortably between the styles for both procedural code and object-oriented code depending on the circumstances in which we find ourselves.

Baseball Bats

Most of us have played or watched a game of baseball, or at least are familiar with some athletic event where a long stick is held with both hands, such as cricket, ice and field hockey, lacrosse, golf, and pole vault. Most baseball players have a preference for holding the bat with the thumb of one hand touching or close to the pinky of other hand, a preference also applicable when holding the stick in those other sports mentioned. When held this way, whichever direction the bat is pointing in reference to the player holding both arms extended straight forward indicates whether the player is left-handed or right-handed. Once baseball players develop some skill with the game, they are most competitive when holding the bat their favored way, but can barely function when holding it opposite-handed. A few players are skillful when holding the bat either way; in baseball they are known as switch-hitters, able to “swing both ways,” and are prized by their teams since they can stand in the batters box on whichever side of home plate gives them the most advantage at that point in the game, such as batting left-handed against a pitcher who is strongest against right-handed batters.

With baseball, swinging a bat left-handed is neither more difficult nor less difficult than doing so right-handed, but we will find one way to be more difficult than the other only after our preferred way of swinging the bat becomes subconscious and we no longer need to think about it. As with baseball bats, we want to develop our programing skills to be able to “code both ways,” so that we are equally comfortable whether it is procedural or object-oriented code pitched at us.

Keyboards

Consider for a moment the keyboard you use to write code, which perhaps is the familiar QWERTY keyboard, so named because these are the first six letters of the first row of letters on the keyboard. Probably you have such facility with the keyboard by now that you do not even think where letters are located; typing has become second nature to you. The location of the letters on the QWERTY keyboard has an historical significance dating back to the time when typewriters were mechanical machines. These first generation typewriters had metal arms called type bars aligned in a semicircle within the machine, with each arm connected to one of the keys of the keyboard. At the other end of the metal arm was the “type,” the print character that would strike a ribbon and leave the ink impression on the page. Typing characters in rapid succession would result in the type bar for one character retreating from the page and the type bar for another character advancing to strike the page. Some combinations of characters would cause adjacent type bars to move, with the respective type bars hitting each other as one was retreating and the other advancing, often causing jams that needed to be fixed manually. After some study, the characters were placed on the keys to avoid the most common combinations of characters from being adjacent type bars, and QWERTY was the result.

Now that typewriters have become relics of a past era, with their mechanical type bars having been replaced by electronics, there is no longer a need for the QWERTY keyboard. The constraint that caused this key arrangement to be invented in the first place no longer exists. Yet today we still use the QWERTY keyboard due to its use having become automatic for so many typists over the decades. Upon first seeing a QWERTY keyboard, many school children inquire why the letters are not arranged in the familiar alphabet series with which they recently have become familiar, and even some adults new to typing wonder why this keyboard is arranged the way it is as they struggle to master it. If we were to ask adults who have acquired some skill with the QWERTY keyboard to consider now using a keyboard where the letters are arranged in the alphabet series, we probably would find them resistant to the idea.⁷ Here again, people respond this way because it becomes difficult to learn anything that deviates from what already has become established as second nature. Similarly, we want to hone our facility with object-oriented programming concepts to the point where it becomes second nature to us to the same degree as our facility with procedural programming concepts.

Programming from the Subconscious

The point here illustrated by flip turns, baseball bats, and QWERTY keyboards is that some aspects of our lives become automatic and subconscious, and this includes writing programs. We simply need to absorb the new programming paradigm into our subconscious, so that we can make the automatic response dependent on the programming paradigm in which we find ourselves writing code. It is not so much a case of difficulty with a new style as it is with what we are capable and incapable of doing subconsciously and automatically.

Getting Back on the Horse

Many readers may have already tried learning object-oriented programming on their own once before, abandoning the effort prior to completion when it became evident the task was more challenging than anticipated. This often leads to the perception that learning the concepts of object-oriented programming on one’s own is an insurmountable obstacle.

After starting and abandoning an endeavour at the first sign of a problem, one usually is advised to “get back on the horse,” a phrase meaning that one’s confidence in overcoming a challenge should not be allowed to be defeated by the first fall, but simply to try again, perhaps using a different approach. Accordingly, this book provides a different approach for those who may be seeking one.