Object-Oriented Design with ABAP

Object-oriented design offers many new concepts for you to explore, so you will want to be certain you've taken the necessary precautions to insure a successful expedition into this new realm. Accordingly, take a moment to prepare yourself for the adventure you are about to undertake, to pause and give consideration to both the journey itself and the expectations you have about what you will encounter along the way.

The associated concepts are applicable to virtually all object-oriented languages, so you will not see anything specific to ABAP in this chapter. Some new vocabulary will be introduced to describe the corresponding concepts and some suggestions will be presented for how to approach the task of extracting design information from the paragraphs found in associated requirements documentation.

You’ll start your journey to Objectropolis from the perspective of Encapsulation, largely because this is the object-oriented design concept with which most procedural programmers already are familiar.

The next stop on your journey to Objectropolis takes you from Encapsulation to a place called Abstraction.

The next stop on your journey to Objectropolis takes you from Abstraction to a place called Inheritance.

The next stop on your journey to Objectropolis takes you from Inheritance to a place called Polymorphism.

The ubiquitous GUI interface enables people to interact with a software system. Many ABAP programmers are familiar with the acronym RICEF, in which the “I” represents Interfaces and most often is associated with data exchanges with external systems.

It has been a long and winding road from Procedureton, but finally you have reached your destination of Objectropolis.

You are about to leave the terrain provided by the basic principles of object-oriented design over which you traveled to arrive in Objectropolis and to reach for the stars in the galaxy known as Design Patterns. You need to acquire some expertise with celestial mapping and cosmic diagramming to help you navigate through this expanse. The Unified Modeling Language provides you with this skill.

Now that you know the basic principles of object-oriented design and have become familiar with the class diagrams offered by the Unified Modeling Language, you are now ready to begin your exploration of the galaxy known as Design Patterns.

YYou will find this design pattern useful when you need to guarantee that there is only a single instance of a class available during execution.

A Swiss Army Knife is a versatile, foldable, pocket-sized, multi-tool utility containing a variety of pivoting attachments suitable for use in everyday circumstances. Its handle is shaped to offer both comfort and dexterity to the person using it.

The next stop on your voyage through the Design Patterns galaxy takes you to the Observer design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful in situations where one class needs to be kept aware of changes occurring in another class.

The next stop on your voyage through the Design Patterns galaxy takes you to the Factory patterns, a collection of three distinct patterns (only two of which are found in the GoF catalog). You will find these design patterns useful to simplify the creation of class instances.

The next stop on our voyage through the Design Patterns galaxy takes us to the Adapter design pattern, another of the design patterns found in the GoF catalog. We will find this design pattern most useful once the maintenance cycle has begun on software components.

The next stop on your voyage through the Design Patterns galaxy takes you to the Decorator design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful in dynamically applying additional responsibilities to objects.

The next stop on your voyage through the Design Patterns galaxy takes you to the Chain of Responsibility design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful when you need to perform specific processing but want to avoid tight coupling between the requester and the servicer.

The next stop on your voyage through the Design Patterns galaxy takes you to the Iterator design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful when you need to access the elements of a structure sequentially without having to know the representation of those elements.

The next stop on your voyage through the Design Patterns galaxy takes you to the Template Method design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful when you need to establish a fixed sequence of steps while allowing for some flexibility in their implementation.

The next stop on your voyage through the Design Patterns galaxy takes you to the Command design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful when you want to trigger the execution of an activity without having to know what the activity is.

The next stop on your voyage through the Design Patterns galaxy takes you to the Null Object design pattern, the first of two design patterns you'll encounter that are not registered in the GoF catalog. You will find this design pattern useful in reducing conditional logic.

The next stop on our voyage through the Design Patterns galaxy takes us to the State design pattern, another of the design patterns found in the GoF catalog. We will find this design pattern useful when we need to make an object behave differently based on its internal state.

The next stop on your voyage through the Design Patterns galaxy takes you to the Lazy Initialization technique, the second of two design patterns you'll encounter that is not registered in the GoF catalog. You will find this design pattern useful in optimizing components.

The next stop on your voyage through the Design Patterns galaxy takes you to the Flyweight design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful in optimizing components.

The next stop on your voyage through the Design Patterns galaxy takes you to the Memento design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern useful when you need to be able to reset the internal state of an object to some previous setting.

The next stop on your voyage through the Design Patterns galaxy takes you to the Visitor design pattern, another of the design patterns found in the GoF catalog. You will find this design pattern most useful once the maintenance cycle has begun on software components.

The next stop on your galaxy quest through Design Patterns takes you to the alternative universe known as Design Anti-Patterns. Nothing from this region is registered in the GoF catalog.

Much has been learned over the years about what constitutes good object-oriented design, some of which has been gained at the expense of object-oriented pioneers, who, through trial and error, have discovered cases of poor design and have shared their knowledge with those of us who otherwise would find out the hard way why some designs are not viable.

Congratulations! You have reached the end of this book. If you have also been diligent in keeping current with the exercises, then perhaps you are able to reflect upon all your hard work and recognize all the new concepts you have not only learned but also reinforced through the exercises. Perhaps you have even experienced some of your own Aha! moments when an elusive object-oriented concept finally became clear for you.

Table A-1 shows the comparison of capabilities offered by ABAP function groups and ABAP object-oriented classes. The √ symbol denotes support for the capability, while the Ø symbol denotes no support.

A zip file available for download at