1.4 Mapping Abstraction and Separation to Classes and Objects
Software development focuses on rendering abstractions in forms that allow them to be manipulated within a software system. An abstraction was described as a collection of attributes and a behavior. As shown in the figure below, the attributes of an abstraction are mapped to a set of data (variables, array, lists, complex data structures, etc.) and the behavior of an abstraction is mapped to a set of methods (also known as operations, functions, actions). The rendering of abstractions in software has always been the implicit goal of programming, though it may have been overshadowed by more mechanical considerations.
Object-oriented programming brings to the task of capturing abstractions in software more sophisticated structures, namely classes and objects, for representing abstractions. These new software structures permit abstractions to be represented more easily, directly, and explicitly.
A class defines the specific structure of a given abstraction (what data and methods it has, how its methods are implemented). The class has a unique name conveying the meaning of the abstraction that it represents. The term class is used to suggest that it represents all the members of a given group (or class). For example, a SalesPerson class might represent all individuals in the group of "people selling cars at an automobile dealership." An object represents a specific member of this group.
Separation of interface from implementation is used to divide the class into two parts, commonly referred to as the private part and the public part. The data and methods are mapped to these two parts of the class as shown below. This separation of private data and code from the visible names of methods results from long years of software engineering experience showing that it is important to protect the data against unexpected, unwanted, and erroneous access from other parts of the software that is manipulating the object. The separation also serves to hide the algorithm used to perform a method.
The relationship of a class to abstraction and separation are reflected in the following definition:
The obvious similarity in the definitions of the terms abstraction and class underscores how explicitly and directly a class is meant to model a real-world entity.
It is interesting to note that there are object-oriented languages that do not have classes but use other techniques to achieve a similar effect. Languages like C++, Java, and others that have a class concept are referred to as "class-based languages."
While a class defines the structure of an entire collection of similar things (e.g., anyone who is a SalesPerson), an object represents a specific member of that class (e.g., the salesperson John Smith who has a commission rate of 15 percent, etc.). The class definition allows the common structure to be defined once and then reused when creating new objects that need the structure defined by the class. An object's properties are exactly those described by the class from which it was created.
The key aspects of the object structure, as shown below, mirror the structure of the class from which it was created. As with a class, the two main parts of an object are its:
In the figure below, the methods that can be invoked from outside the object are shown as small dark circles on the object's boundary. The code that implements the methods is part of the object's implementation and is hidden inside the object. The term "encapsulation" is often used to describe the hiding of the object's implementation details; it is common to read that "an object encapsulates its data." Encapsulation is defined as:
The notion of encapsulation is fundamental to an understanding of objects and object-oriented programming.
Mapping an Abstraction to a Class
The interactive figure below illustrates how a class is a software structure capable of representing an abstraction. The left part of the figure is the same as that used earlier to illustrate how abstraction is a process of simpification. Once an abstraction has been created using the controls on the left side, a class can be formed using the controls on the right part of the figure. The "Define Attributes" and "Define Behaviors" buttons buttons show how the attributes and the behaviors of the abstraction are mapped to the private and public parts of a class, repectively. The "Encapsulate" button shows visually the logical effect of encapsulating the private parts of a class definition. Visually, the private part of the class definition is blacked-out to suggest that the private elements of the class cannot be seen outside of the class. The "Decapsulate" button re-exposes the private elements. The "Reset" button returns the class definition area to its original condition.
The term instantiation is used to describe the act of creating an object from a class and the object is called an instance of the class. Numerous instantiations can be made of a given class, each yielding a distinct object. This leads to definition of an object as:
This definition highlights the fact that all objects that are instances of a given class are structurally identical: they have the same arrangement of data and can respond to the same set of method invocations. However, as shown in the following figure, each object may, and usually does, have different values for its data. In the figure there are two instances of the SalesPerson class. Both objects encapsulate the same type of data (name, commissionRate, and totalSales). The two objects currently have different values for the name and totalSales data but they currently have the same value for the commissionRate data. Both objects have two methods that can be invoked: sellCar and reportSales.
The relationship between a class and the objects that can be created using the class is often likened to that of a factory and the things produced by that factory. An automobile factory produces automobiles in the same way that an Automobile class can be used to create Automobile objects. Likewise, an Automobile class can produce only Automobile objects just as an automobile factory can produce only automobiles, not vacuum cleaners or rocket ships.
Creating Objects from a Class
The interactive figure below illustrates how multiple objects can be created from a single class and coexist with objects of other classes. The left and right hand parts at the top of the figure are the same as those used previously to illustrate the process of forming an abstraction and how an abstraction is mapped to a class. These elements operate in the same way as in the previous examples. The bottom part of the figure is new.
The bottom part of the figure is an area in which objects can be created, and manipulated. This area is controlled by two buttons. The "Make Object" button creates a graphical representation of an object of whatever class is currently defined in the right part of the top of the figure. Several objects of the same class can be created or objects of different classes can be created. The "Clear Objects" button erases all of the objects in the lower part of the figure.
An object that is displayed in the lower part of the figure can be manipulated as follows. A method can be executed on a given object by clicking on that method's name. A dialogue box will appear into which the arguments of the method can be entered or in which the returned result from the method is displayed. The private data of each object is visible in the object's representation to aid in understanding how the object is affected by each of its methods.
Classes and objects are often discussed by developers in lifelike, personal, anthropomorphic terms: a developer might say "The class should not be responsible for that," or "I expect the object to reply to inquiries about its current state." The developer may even assume the object's identity to better understand its role in a system's design. In this mode, a developer may ask, "What is expected of me?," "How will I be able to do that?", or "Why do you want to know that about me?". Questions such as these often lead a developer to a better intuitive understanding of an object and its relation to other objects.
A simple and popular design technique which focuses on identifying for each object (or class of objects) its responsibilities and its collaborators is intuitively related to the anthropomorphic view of objects. This technique . An object's (or class's) responsibilities are those properties or duties the object (or class) is obligated to maintain or perform. An object's (or class's) collaborators are those other objects (or classes) with which the given object (or class) must interact. The terms responsibilities and collaborators, of course, reflect the anthropomorphic view of objects.
The personification of objects reflects the correspondence that developers see between the real-world entity and its abstraction on the one hand, and the classes and objects that are their software counterparts on the other. This view also reflects the autonomy and encapsulation ascribed by designers to objects and classes.