Encapsulation
\oopindex{encapsulation}
The encapsulation mechanism offered by object oriented languages
is embodied by the notion of an object.
In most languages, objects are defined by a class declaration
that characterizes the properties of the objects
belonging to that class.
In operational terms, a class may be regarded as a template
for creating objects.
Objects
\oopindex{objects}
may be thought of as structures that comprise both data and procedures
that may operate on these data.
Using Smalltalk terminology, we may write down the equation
[M] object = data + methods
The variables that refer to the data contained by an object are often called
instance variables, since such variables are privately owned by
each instance of a class.
Methods{\rm ,}
\oopindex{methods}
in Smalltalk, have exclusive access to the instance variables of the object
for which they are defined.
The methods of an object are, no more and no less,
priviliged procedures that may operate on the data of an object.
In other words, methods provide a functional abstraction mechanism
that allows the contents of an object to remain hidden.
A pictorial representation of an object counter, containing an instance variable n,
and supporting the methods initialize, increment and value is given below.
.so instance
Messages
\oopindex{messages}
A method is executed for an object in response to a message.
For a message to be a legal method call, the method must be defined in the method interface
of the object.
Methods that are private to an object may not be called.
\oopindex{method interface}
Operationally, we may regard an object as encapsulating
a state that is dependent on the values of the instance variables,
and behavior that results from the functions embodied
in the methods defined for the object.
We may capture this operational view in the equation
[M] object = state + behavior
that closely corresponds to our previous characterization of an object
as encapsulating data and methods.
Computation in an object oriented system is sending messages.
Sending a message to an object may result in a change of the state of the object
and may possibly cause the object to send messages to other objects.
We may remark, following [St88], that an object oriented language supports
data abstraction to the extent that access to the state of an object is
effectively forbidden,
except for the methods defined for the object.
To provide further protection, some languages allow to define an external
method interface
that states which methods are externally visible.
Responsibilities
\oopindex{responsibilities}
In addition to the syntactic and operational characterization
given of objects, we may characterize an object from the
perspective of program development as an entity with certain responsibilities.
From this perspective an object can be regarded as providing
a service in response to a message.
We will refer to the object sending a message to ask for a service
as a client of the object that supplies the service.
\oopindex{external interface}
The external interface of an object,
that comprises the methods visible to the clients of an object,
may now be viewed as stating the responsibilities of an object,
that is the services it is willing to supply.
\oopindex{constructors}
\oopindex{destructors}
\oopindex{modifiers}
\oopindex{selectors}
\oopindex{iterators}
As concerns the operations of an object (its responsibilities),
a distinction can be made between methods to create and initialize an object (constructors),
methods to dispose of an object (destructors),
methods to change the state of an object (modifiers),
methods to evaluate the current state (selectors) and methods
to visit parts of the object (iterators).
In a design, the description of an object will usually
not contain a precise characterization of its constructor and destructor methods.
However, when objects have activity of their own, the constructor characterizes this
activity or may lay down the protocol for interaction with other objects.
In these cases, the description of the constructor enhances a conceptual understanding
of the functionality of the object.