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.