Abstraction is a design technique that focuses on the essential aspects of an entity and ignores or conceals less important or nonessential aspects. Abstraction is an important tool for simplifying a complex situation to a level where analysis, experimentation, or understanding can take place. For example, in attempting to understand the mechanics of the solar system, early mathematicians and astronomers applied abstraction to a "planet," treating the planet as a body, all of whose mass is concentrated at a single point. Such an abstraction ignores a wealth of details about each planet -- its actual diameter, its atmospheric content, its average temperature -- which are not relevant to understanding and modeling the basic orbital mechanics of the solar system.
In software, abstraction is concerned with both the "attributes" and "behavior" of entities. Attributes are the properties or characteristics associated with an entity, while behavior refers to the set of actions that the entity can perform. In a software object, attributes are represented by data that is associated with the object. For a sales-tracking system, relevant attributes of a salesperson might be: name, number of vehicles sold, value of vehicles sold, list of customers, commission rate, total commissions. An action, or behavior, of the object corresponds to an operation or function associated with the object. Actions for a "salesperson" might include "sellCar," "reportIncome," and "increaseCommisionRate."
Abstraction is vital to creating tractable software objects because the real-world objects are far too complex to be captured in complete detail. Consider the simple salesperson object referred to above. A real salesperson has an identity, a family genealogy, a medical history, a genetic profile, a credit record, a set of talents, and many more unique attributes. Similarly there is a rich set of actions of which the salesperson is capable (sellCar, answerPhone, buyHouse, haveChild, getSick, increaseCreditLimit, payBills, etc.). Trying to capture even a small part of this enormous detail in a software object is pointless. It is important to capture only those aspects of a salesperson that are relevant to the development of a particular system (e.g., the sales-tracking system).
The objects in an object-oriented system are often intended to correspond directly to entities in the "real world". Objects, such as "salesperson" and "automobiles," that might occur in an automobile-dealership tracking system correspond to the actual people on the staff of the dealership and the actual cars owned and sold by the dealership. The correspondence between the software objects and the real-world entity that they represent is sometimes so direct that computer-based theft or fraud often involves tampering with the software objects that are trusted by others to correspond to real-world artifacts. This sense of correspondence is also expressed as the program being a simulation or model of the real world, changes in one being reflected in the other. A "good" program is one that models or simulates accurately what is happening in the real world.
The figure below can be manipulated to illustrate the concept of abstraction for a SalesPerson. The blue portion of the figure represents the real-world person, while the yellow portion of the figure represents an abstraction, acting as a filter that makes visible only those aspects of the real-world entity that are relevant to the abstraction being formed. Move the yellow filter around in the figure to see what attributes of the real-world entity are relevant.
The examples above motivate the following definition of abstraction:
This definition also reflects the fact that for computer scientists and software engineers abstractions are not "abstract," ethereal concerns. Instead, abstraction is used to form concrete manifestations of the abstraction. At different stages in the software lifecycle the representation of an abstraction may take different forms. In the early design stages, hand-made drawings, diagrams, and lists may be used. Further in the design stage, a specific design notation may be used, often supported by design tools. Finally, in the implementation stage, the abstraction is represented in software, where it may be visible to the user and capable of conducting interactions with the user.
A single entity may have many valid abstractions. While the genetic profile of a salesperson is not relevant to a sales-tracking system, it may be relevant to a medical database system as shown in the figure below. Correspondingly, the medical-database system developer would not consider the number of vehicles sold to be a relevant aspect. The name of the abstraction is useful to distinguish among different abstractions for the same entity and among abstractions for different entities. A critical part of object-oriented design is deciding which attributes and behavior to include in a given abstraction.
The figure below can be manipulated to illustrate the concept of abstraction for a patient in a medical database. The blue portion of the figure represents the "real world" person. The yellow portion of the figure represents an abstraction as a filter that makes visible only those aspects of the real-world entity that are relevant to the abstraction of this person from the point of view of a medical database application. Move the yellow filter around in the figure to see what attributes of the real-world entity are relevant.
The interactive figure below illustrates the process of forming an abstraction by simplifying the description of a real-world entity. The central (yellow) areas shows a representation of a complex real-world entity - a person. A real person has many attributes (shown in black) and is capable of many different behaviors (shown in blue). The central area shows some of a person's attributes and behaviors. You could clearly think of many more of each. The person may be viewed from many different perspectives, each view yielding a different abstraction. Select one of the four different views (SalesPerson, Student, CarOwner, and Patient) and press the "Do Abstraction" button. The animation shows the simplification that results by viewing the person from the selected viewpoint. The "Reset" button returns the interactive figure to its original condition.
These properties are clearly subjective and qualitative in nature, implying that the ability to form good abstractions requires good judgment as well as the benefit of practice and experience.