Abstract Art

One good way to envision abstraction is to consider how a cartoon image conveys information about an entity.

If I were to try to describe a car to you, I might draw a cartoon picture of a car, applying to it only those details relevant to the discussion. The cartoon would be an abstraction of a car. It would not represent any particular car, but merely serve as a generalization for any car simply to facilitate the discussion I wanted to have about cars. The discussion might be about car windshields. If at some point in the discussion I were to tell everyone to go outside into the parking lot to find a car with the type of windshield I was discussing, it is unlikely that everyone would gravitate to the same car. This is because my cartoon image of the car would not exhibit enough detail for everyone to identify the same car; it is simply an abstraction for any car possessing the level of detail I provided for it.

Another way to envision abstraction is to consider how authors of romance novels develop their characters. A typical trio of characters is hero, villain, and damsel in distress. Each of these characters is developed as the novel progresses, but the author provides only enough information about them to support the story, and we use our imagination to fill in the missing details. Accordingly, each reader of the novel creates their own unique images of each character, perhaps drawing upon similarities with themselves or people they know, enjoying the novel even though each character is an abstraction for a person and not intended to represent any particular person.

Representing Real-World Entities

Car, bank account, and weather forecast are three examples of real-world entities. We can represent these entities in an object-oriented program by defining each one as a class: a car class, a bank account class, and a weather forecast class. These classes represent abstractions for their real-world counterparts.

Each of these classes can include definitions for its attributes. The car class can include attributes for make, model, year, serial number, average miles per gallon, speed, direction, remaining fuel quantity, etc. The bank account class can include attributes for account number, type of account, current balance, minimum balance, interest rate, overdraft penalty, etc. The weather forecast can include attributes for expected high temperature for today; expected overnight low temperature; chance of precipitation for today, tomorrow, the next day; etc.

Each of these classes can also include definitions for behaviors that act upon its attributes. The car class can include behaviors for start, stop, turn and accelerate, each having an effect upon the attributes retaining information about fuel consumption, movement, and direction of travel. Likewise, the bank account class can include behaviors for deposit, withdraw, and calculate interest, each having an effect upon the attributes retaining information about current balance and overdraft penalty. Similarly, the weather forecast class can include behaviors for both updating and disclosing its own attribute values for tracking the weather.

So, how is this different from the procedural programming style with which we are so familiar?

While procedural programs are primarily designed to address a specific processing requirement, classes are primarily designed to manage information. The car class manages information about a car, but has no capacity to manage any other type of information, such as how many other cars have ever been owned by the driver, information that, while it might be important to us, has nothing to do with the car class.

Let’s see this through an example. A manufacturer of replacement vehicle mufflers needs to track the quantity and location of finished goods in transit between its manufacturing plant in Cleveland, Ohio and its three regional warehouses in Linden, New Jersey; Kansas City, Missouri; and Hayward, California, each of which receive their inventory of mufflers via shipping containers moving by both rail and truck. A report is required to show the various shipping containers in use, indicating the container id, which of them are being loaded, which are being unloaded, and for those in transit, which are on trucks and the name of the trucking company, which are on rail cars and the name of the railroad company , where each one is located, the warehouse to receive the shipping container, and its estimated time of arrival. The format of the report is similar to the output shown in Table 4-1.

When writing this program using the procedural style we might define a global variable as a table to keep track of all the information required for shipping containers as well as other variables to record information about the three warehouses, the trucking companies, the railroad companies, and the manufacturing plant. It may be composed of various subroutines for resolving the information about each shipping container and presenting this information in a report. Such a program is designed like many other procedural programs: it focuses on the processing requirement.

When writing this program using the object-oriented style we might define classes for shipping container, warehouse, manufacturing plant, truck, trucking company, rail car, railroad company, and report. Each of these classes is an abstraction of its real-world counterpart and has its respective attributes and behaviors. The report class produces the report while the shipping container class keeps track of information about a single shipping container. Each class retains information relevant to the abstraction it represents and no other information. Such a program is designed like many other object-oriented programs; it focuses on data and how the data is organized and managed.

Comparing the two programming styles illustrated above, we see that the procedural program contains information about every contributing entity all combined into one single program. There is no discernible separation between a shipping container and the truck that might be carrying it, since information for both is retained in the same global table. By contrast, the object-oriented program manages the information by segregating it into distinct classes, where each class manages only the information relevant to it. The shipping container retains the container id and its quantity, but knows nothing about the truck or rail car transporting it.

Class Cohesion

The degree to which members defined for a class are relevant to each other is a measure of the cohesion of a class.⁴ A class containing only those members relevant to its corresponding abstraction reflects high cohesion among its members, while a class containing members that have little relevancy to one another reflects low cohesion. Classes should be defined in a way that offers high cohesion among its members.

In the previous example for the manufacturer of replacement vehicle mufflers, a variety of classes were proposed to facilitate the object-oriented programming style. The class proposed to represent an abstraction for a shipping container offers high cohesion when its attributes and behaviors all relate to each other. For example, its attributes might be container id, color, height, width, depth, storage capacity, tare weight, maximum gross weight, net weight, quantity of loaded items, and current security tag number; and its behaviors might include, load, unload, get_gross_weight, and apply_security_tag. All of them offer the class high cohesion since they all relate to a shipping container. If we were to include for this class an attribute to hold the name of the trucking company moving the container, we would cause the class to offer lower cohesion since this attribute has little to do with a shipping container, but instead is relevant only when a truck is transporting it. It would represent an example of an attribute that would not be applicable when the shipping container is being transported by train. Worse, to include in the shipping container class an attribute to represent the number of employees working for the manufacturer of mufflers the previous year would further diminish the cohesiveness of the class since this information is completely irrelevant to shipping containers.

Reusable Components

The report on shipping containers in use illustrated in Table 4-1 might cause us to consider whether its construction using the object-oriented programming model is worth the effort. An argument could be made that we might be able to complete it faster using the procedural programming model. This is a good point to ponder, but we should consider that rarely do we ever encounter business organizations where only one type of report provides sufficient information about business entities such as shipping containers. Instead, we are likely to find ourselves given requirements later to write a report on those shipping containers that are out of circulation due to having sustained damage or in the process of being repaired and refurbished, on the current age and expected lifespan of active shipping containers, and a host of other reports related to shipping containers.

With this in mind, it makes sense to use the object-oriented programming model so that the shipping container class we define for the in-use report can also be reused with these other reports. Not only that, but during the maintenance of each report it becomes easier to identify the discrete component having responsibility for managing the information we seek to convey in the report. Eventually we will have compiled a comprehensive library of reusable components , each component representing a ready-to-use abstraction for an entity that needs to participate in the next new report program that becomes necessary.

Establishing a Level of Abstraction

An abstraction level provides aspects for both detail and scope of an entity and is a measure of the precision we choose to assign it. This provides us with the ability to manage the complexity of an entity through a more practical perspective, allowing us to ignore details that may not be relevant to the way in which we need to use the entity. We see more detail at lower levels of abstraction and fewer details at higher levels. Similarly, we are afforded wider scope at higher levels of abstraction and narrower scope at lower levels. The two aspects of detail and scope have an inverse relationship with each other; as one increases, the other decreases.

For example, we might find ourselves standing on a patio adjoining the back of a house. The patio is composed of common red bricks measuring about 20cm long x 10cm wide x 5cm deep and they arranged in a herringbone pattern, such as presented in Figure 4-1.

Figure 4-1. Herringbone pattern

When we are standing on the patio, our eyes are about five feet above it. At this level of abstraction, when we look down at the patio, we can see distinct red bricks in a herringbone pattern. If we were to raise our abstraction level to 50 feet above the patio, we now might see red blocks arranged in a herringbone pattern; however, we can no longer identify that they are bricks. Raise the abstraction level to 500 feet and we might see that the patio is red, but we can no longer tell there is a herringbone pattern. At 5,000 feet, we can no longer tell that the patio is red. At 50,000 feet, we can no longer see the patio.

Similarly, at the five-foot abstraction level, our scope is limited to only the portion of the patio on which we are standing. At the 50-foot abstraction level, our scope widens and we can see the entire patio, the roof of the adjoining house, and some of the yard surrounding it. At 500 feet, our scope widens still more and we also can see some of the neighbors’ houses and their patios . At 5,000 feet, we can see the entire town. At 50,000 feet, we can see the entire county.

Table 4-2 organizes these different vertical perceptions of patios, enabling us to compare the corresponding scope and level of detail as we change our level of abstraction.

Let’s put this into terms of classes and their members. Suppose we have three classes representing three different abstraction levels:

1. Enclosed shape

2. Enclosed shape with at least one angle

3. Rectangle

We have arranged these classes in Figure 4-2 to illustrate the vertical nature of the relationship between these classes, with each class providing less scope and more detail as we descend from the top of the chart to the bottom.

Figure 4-2. Classes arranged where scope is greatest at top and level of detail is greatest at bottom

Now we will ask three people selected at random (Boris, Natasha, and Sherman) to provide two-dimensional drawings for each class, instructing them to “use your imagination” but stay within the constraints as described by the name of the class. As shown in Figure 4-3, none of these people provided the same drawing, but all their drawings conform to the criteria described by the name of each class.

Figure 4-3. Drawings provided by Boris, Natasha, and Sherman

Let’s define some members for these classes.

Area and perimeter are two attributes we should be able to apply to any two-dimensional enclosed shape , so for the Enclosed shape class we’ll define these two attributes and two corresponding methods, getArea and getPerimeter.

The Enclosed shape with at least one angle class can accommodate all of the members defined for Enclosed shape, but this class is at a lower level of abstraction, providing more detail and less scope. Its scope is limited to those drawings with at least one angle, and so cannot accommodate the drawings for the Enclosed shape class provided by Boris and Natasha. However, because its level of abstraction includes the detail “at least one angle,” we can define for it additional members to reflect this level of detail. Let’s define for it an attribute called smallest angle and a corresponding method getSmallestAngle.

Similarly, the Rectangle class can accommodate all of the members defined both for Enclosed shape and for Enclosed shape with at least one angle. Since it has a lower level of abstraction than Enclosed shape with at least one angle, let’s capitalize on this and provide it with an attribute called hypotenuse and a corresponding method named getHypotenuse. Here we specify for Rectangle more detail, but we also know that its scope does not permit it to accommodate any of the drawings for the Enclosed shape or Enclosed shape with at least one angle classes provided by both Boris and Natasha.

Sherman provided the same drawing for all three classes; however, we need to recognize that even though a rectangle was provided for the Enclosed shape class, this class has neither a hypotenuse attribute nor a getHypotenuse method. The Enclosed shape class can determine only the area and the perimeter of a rectangle since this is the extent of information its level of abstraction allows it to see for the drawing it holds.

Table 4-3 summarizes our three classes and their respective members.

Notice that, by virtue of its additional members, each successive class represents a specialization of the one preceding it. Another way of looking at this is to consider that each preceding class represents a generalization of the one following it. As we move from a more general to more specific class, we can accommodate a smaller set of applicable shapes but we gain detail about each one (additional members of the class). Similarly, as we move from a more specific to more general class, we can accommodate a larger set of applicable shapes but we lose detail about each one (fewer members of the class). The set of shapes that can be considered a Rectangle is a subset of the larger set of shapes that can be considered an Enclosed shape with at least one angle. Likewise, the set of shapes that can be considered an Enclosed shape with at least one angle is a subset of the larger set of shapes that can be considered an Enclosed shape.

We can correlate this set of classes and their respective members with the perspectives illustrated by the patio metaphor noted above. Let’s imagine the Rectangle class offers us a perspective on shapes from 50 feet away, the Enclosed shape with at least one angle offers a perspective from 500 feet, and Enclosed shape offers a perspective from 5,000 feet. At 50 feet, we can see via Rectangle that a shape has an area, perimeter, smallest angle, and hypotenuse. At 500 feet, we can see via Enclosed shape with at least one angle that a shape has an area, perimeter, and smallest angle, but we can no longer see whether it has a hypotenuse; this perspective offers us fewer details. However, the shapes we can see are now no longer limited to rectangles; it offers us a wider scope of applicable shapes. Similarly, at 5,000 feet, we can see via Enclosed shape that a shape has an area and a perimeter, but we can no longer see whether it has either a smallest angle or a hypotenuse, offering us even fewer details. However, the shapes we can see are now no longer limited to those with at least one angle, offering us a wider scope of shapes .

Suppose we find ourselves with the requirement to create a report that shows the area and perimeter of a set of shapes. Which of the classes shown in Table 4-3 should we choose to facilitate this? The most appropriate class would be the Enclosed shape. It provides the necessary level of detail to reflect the area and perimeter of any shape we might encounter. Whereas one of the shapes our report program may encounter could be a rectangle, and there is a Rectangle class among the choices above, the report does not need to use any attribute or behavior applicable specifically to rectangles. The smallest angle and hypotenuse attributes offered by the Rectangle class represent details beyond those required for a report showing simple area and perimeters of shapes. Accordingly, our report does not need to know that it is working with a rectangle to produce the information required; the Enclosed shape class is a sufficient level of abstraction to handle any rectangle shapes that would participate in the report.

Multiple Instantiations

Once we have established its level of abstraction, we now have a class that can act as a proxy for its real-world counterpart, offering only the level of detail applicable to the entity it represents. We also have a pattern for an entity from which multiple instances of the entity may be created. There is a word used to describe each instance of an abstraction: object.

This is the very foundation for the term “object-oriented” in describing both the language and the design concepts associated with object-oriented programming.

Classes define these entities. Objects are their instantiation. In this context, object means the same thing as instance of a class . In a single program there is virtually no limit to the number of objects that can be instantiated for a class. Once an object is instantiated, it becomes a concrete representation of the abstraction, because although objects of the same class all have the same attributes and behaviors according to the class definition, each object has its own unique attribute values.

While abstraction represents a conceptualization for some entity, a concretion denotes a tangible instance. Table 4-4 gives some other examples of the relationship between abstraction and concretion.

Relationship Between Abstraction and Encapsulation

The principles of abstraction and encapsulation have a complementary relationship. A class is an abstraction of an entity and the class encapsulates the attributes and behaviors relevant to the corresponding level of abstraction represented by the class.

Steve McConnell, author of Code Complete, offers an interesting perspective on this. After summarizing the concept of abstraction with the following paragraph:

• Abstraction is the ability to engage with a concept while safely ignoring some of its details – handling different details at different levels. … If you refer to an object as a “house” rather than a combination of glass, wood and nails, you’re making an abstraction. If you refer to a collection of houses as a “town,” you’re making another abstraction.⁵

he describes the relationship between abstraction and encapsulation with this exquisite passage:

• Encapsulation picks up where abstraction leaves off. Abstraction says “You’re allowed to look at an object at a high level of detail.” Encapsulation says, “Furthermore, you aren’t allowed to look at an object at any other level of detail.”⁶

driving the concept home with this explanation:

• Encapsulation says that, not only are you allowed to take a simpler view of a complex concept, you are not allowed to look at any of the details of the complex concept. What you see is what you get – it’s all you get!⁷

where the simple view of a complex concept is represented by an abstraction .

ABAP Language Support for Abstraction

The object-oriented extensions to the ABAP language accommodate abstraction in the following ways:

• By providing the ability to define representations for real-world entities

• By providing the capability to establish a clear level of abstraction

• By supporting the concept of creating multiple instances of a class

The same statements we saw for encapsulation also enable us to accommodate abstraction, with the construct block

class class_name definition [options].
  o
  o
  o
endclass.

providing the ability to define representations for real-world entities and establishing clear levels of abstraction through judicious selection of a class name, and also facilitating effective class cohesion by establishing the boundaries for containing the members to be included in the class.

Among the options available on the class definition are the qualifiers abstract and final. A class may have either or both of these qualifiers, and, as discussed in the section on encapsulation, when both are present it indicates a static class. As described in that section on encapsulation, the qualifier abstract insures that the class cannot be instantiated. It is the absence of the abstract qualifier that enables instances of the class to be created.

Another of the class definition qualifiers, the create qualifier, controls the creation of instances of the class. The create qualifier is followed by a word ascribing an instantiability level to the class and restricts the relationship an entity must have with the class for it to be able to create an instance of the class. The syntax is

... create [public | protected | private] ...

where create private means that only the class itself may create instances of the class; create protected means that only the class itself and any inheriting subclasses may create instances of the class; and create public means that any entity may create instances of the class. When not explicitly indicated on a class definition statement, create public is the default.

Notice the similarities between the words used to assign visibility levels for class members discussed in the section on encapsulation and the instantiability level available with the create qualifier of the class definition statement noted above, where object creation levels also indicate gradations from most visible to least visible. The visibility of the members of a class and the instantiability level assigned to the class are completely independent of each other. However, the same implications class friendship has upon visibility levels of class members also apply to the ability of a class to be instantiated by a friend class; specifically, the instantiability level of a class also is elevated to create public for its friends regardless of the actual create level assigned on its class definition statement.

In addition, the ability to create multiple instances of a class is facilitated by the use of the same class name on multiple reference variables and then creating instances of the same class into each one of these, as illustrated in this example:

report.
  o
  o
  o
    data         : rental_car     type ref to car
                 , classic_show_car
                                  type ref to car
                 , limousine      type ref to car
                 , hearse         type ref to car
                 .
  o
  o
  o
    create object: rental_car
                 , classic_show_car
                 , limousine
                 , hearse                                    
                 .

Orienting Ourselves After Having Traversed Abstraction

So, we have made more progress on our journey from Procedureton to Objectropolis, and now, having completed our traversal through the object-oriented district known as Abstraction, we are familiar with its principles and can now converse in the dialect characteristic of the local population. The landscape in Abstraction may have some similarity with that of our home town of Procedureton, but it also offers some new exotic features. Even so, we have become familiar with the peculiarities commonplace in this district and feel confident we can orient ourselves to maneuver effectively over the terrain of Abstraction.

Refer again to the chart in Appendix A, illustrating the comparison between function groups and classes of how each one facilitates the capabilities of the principles of object-oriented programming. Rows 11 through 14 show how these two programming formats support the principles of abstraction. We can see that function groups offer some support for this principle.

Summary

In this chapter, we became more familiar with the object-oriented concept of abstraction. We learned that classes are used to represent abstractions for real-world entities and reinforced the idea that a significant difference between procedural and object-oriented design is their primary focus on processes and data, respectively. We were introduced to the concept of class cohesion, a measure of the relevance a member of a class has to all its other members. We also are familiar with two aspects associated with abstraction:

• Level of abstraction

• Multiple instantiations

We also are aware of the relationship between the principles of encapsulation and abstraction.

Abstraction Exercises

Refer to Chapter 4 of the functional and technical requirements documentation (see Appendix B) for the accompanying ABAP exercise programs associated with this chapter. Take a break from reading the book at this point to reinforce what you have read by changing and executing the corresponding exercise programs. The exercise programs associated with this chapter are those in the 102 series: ZOOT102A through ZOOT102C.