1.4 Mapping Abstraction and Separation to Classes and Objects
Software development centers on rendering abstractions in a form that
allows 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.
| Mapping Abstractions to Software |
 |
What object-oriented programming brings to the task of capturing
abstractions in software are more sophisticated structures, namely
classes and objects, for representing
abstractions. These new software structures permit abstractions to be
represented more easily, more directly, and more explicitly. Learning
how to use existing classes to create and manipulate objects is the
first step in learning about object-oriented programming. As a user,
you are able to benefit from the hard work already done by the
designer and implementor of existing classes. This ability to reuse
existing classes is one of the major benefits of software reuse, in
general, and object-oriented programming in particular.
Class
A class defines the specific structure of a given
abstraction (what data it has, what methods it has, how its methods
are implemented). The class has a unique name
that conveys the meaning of the abstraction that it represents. The
term "class" is used to suggest that it represent 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 is motivated
by 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 General Structure of a Class |
 |
The relationship of a class to abstraction and separation are
reflected in the following definition:
- Class
- A named software representation for an abstraction that separates the
implementation of the representation from the interface of the
representation.
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."
Object
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 instance of that class (e.g., the sales person whose name is
"John Smith", who has a commission rate of 15%, etc.).
The class definition allows the common structure to be defined once
and 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, mirrors the
structure of the class from which it was created. As with a class, the
two main parts of an object are its:
- implementation: the data and the implementation of the methods
that are
hidden inside of the object, and
- interface: the signature of all methods that are visible outside of
the object.
In the figure below, the methods that can be invoked from outside the
object are shown as small dark circles on the border of 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:
- Encapsulation
- in object-oriented programming, the restriction of access to data
within an object to only those methods defined by the
object's class.
The notion of encapsulation is fundamental
to an understand of objects and object-oriented programming.
| The General Structure of an Object |
 |
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:
- Object
- a distinct
instance of a given class that encapsulates its implementation details
and is structurally identical to all other instances of that class.
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 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.
| Multiple Instances of a Class |
 |
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. Also, an Automobile class can produce only
Automobile objects just as an automobile factory can produce only
automobiles, not vacuum cleaners or rocket ships.
Anthropomorphism
Classes and objects are often discussed by developers in life-like,
personal, anthropomorphic terms. A developer might say that "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 identity of the object to better understand the role of the object
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 objects and its
relation to other objects.
A simple and popular design technique is intuitively related to the
anthropomorphic view of objects. This technique focuses on
identifying for each object (or class of objects) its
responsibilities and its collaborators. 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" reflect the anthropomorphic
view of objects.
The personification of objects reflects the correspondence developers
see between the real world entity and its the 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 assigned by designers to objects and classes.
Last Updated: July 24, 1996 / kafura@cs.vt.edu
