5. Encapsulation

e.g., how are object boundaries defined?; how many object boundariesor interfaces are there (do subclasses or "friends" get specialaccess to objects)? what are their characteristics?

OODBTG Reference Model

A key concept of the object paradigm is "encapsulation", whichis defined as a kind of abstraction that enforces a clean separation betweenthe external interface of an object and its internal implementation.

Users of objects are people or programs which send requests to objects.Users of objects observe the behavior of objects in terms of the operationswhich may be applied to objects, and in terms of the result objects returnedby such operations. An operation may be implemented (i.e., supported orrealized) by a variety of different program code and data structures. Encapsulationmeans that these implementations are not visible to the user of the object,hiding details of whether and what data structures or code are used inan implementation. The importance of encapsulation is that it insulatesapplications from object implementations allowing them to be modified withoutrequiring applications that use them to be modified.

Some classical object models define a stronger form of encapsulation,in which the states of objects are isolated from each other; the implementationof objects is disjoint between objects; all methods and states belong exclusivelyto individual objects.

An assumption that attributes or other structural constructs are necessarilyimplemented as stored data would violate encapsulation. An attribute suchas the age of a person, the weight of an assembled object, the circumferenceof a circle, or the font of a word within a document might be stored insome implementations and computed in others. Violations of encapsulation,if allowed at all, should be made explicit (e.g. PUBLIC data in C++).

OMG Core Object Model

4.2.8 Interfaces of a Type

In the Core Object Model a type exports all of the operations that aredefined on it. There is no notion of multiple named interfaces definedon a type that exports less than the full type specification. Visibilityattributes such as private, public, subtype_visible, and friends are notsupported either. These may be defined by components.

There is also no notion of a program binding to a subschema that restrictsa program's access to some subset of the types defined in the system, andfor any type within this subset, further restricts access to some subsetof the characteristics defined by the type. Subschemas and subschema-specificinterfaces to types may also be defined in a component.

4.2.8.1 Example type interface

A type's interface defines the externally visible state and behaviorof instances of the type. Behavior is defined as a set of operation signatures.The following example shows the interface portion of an object type definitionthat illustrates these concepts. The syntax is illustrative only.

type IMAGE   supertypes: OBJECT
  operations:     INTEGER get_length (i:IMAGE)     set_length (i:IMAGE, length: INTEGER)     INTEGER get_width (i:IMAGE)     set_width (i:IMAGE, width: INTEGER)     scale (i:IMAGE, by:FACTOR)     rotate (i:IMAGE, by:DEGREES)     IMAGE crop (i:IMAGE, to:SIZE)
end_type

OMG CORBA IDL

Access to the state of CORBA objects is through the operations thatmake up the objects interface. IDL supports full encapsulation for CORBAobjects.

ODMG

All objects are instances of a type which specifies the interface foraccessing the object. There is only one interface for a type.

EXPRESS

EXPRESS has no notion of encapsulation. All attribute values of an instanceare visible in any context in which the instance itself is visible.

Open Distributed Processing

A fundamental notion of ODP, used extensively. It is not possible to"look inside" any object.

The state of an object is accessible only through invocation of theservices supported by the object. Users (i.e., clients) of objects arepermitted only to know what the object does, not how it does it.

Encapsulation is enforced by only allowing an object to be accessedthrough invoking the operations defined in its interface. This kind ofde-coupling limits dependencies between objects, permitting them to bere-implemented, modified and extended without affecting existing clients.

Editor's Note: there is a need at this point to describe the abilitywithin the ODP model to define multiple interfaces for the same object.

Management Information Model

A facet of object-oriented design is that of encapsulation. Encapsulationensures that the integrity of an object is preserved. This requires thatall operations to be performed are accomplished by issuing a "message"to the object. That is, the internal operation of a managed object is notvisible at the object boundary unless attributes, operations, or notificationsare defined to expose this information. The definition of the managed objectclass specifies what operations can be performed and what consistency constraintsare required to maintain the integrity of the managed object. [Part 1]

SQL3

Each component (attribute or function) of an ADT has an encapsulationlevel of either PUBLIC, PRIVATE, or PROTECTED. PUBLIC components form theinterface of the ADT and are visible to all authorized users of the ADT.PRIVATE components are totally encapsulated, and are visible only withinthe definition of the ADT that contains them. PROTECTED components arepartially encapsulated; they are visible both within their own ADT andwithin the definition of all subtypes of the ADT. SQL3 also supports encapsulationfor tables to the extent that views (derived tables) are considered asproviding encapsulation.

Matisse

Encapsulation is supported through the use of the object paradigm. TheMatisse API allows execution of methods. Attributes may be publicly accessedthrough the API as in C++, but can be hidden from direct access by theuser through constraints as in Smalltalk.

As in all database systems, encapsulation is violated by indexes thatallow rapid scan of the database for selection of sets of objects of interest.Matisse allows any attribute of any object to be an "entry point"or index. By default, the attribute value is the symbolic index to theOID of the object. However, the user can create any "entry point"function and sophisticated algorithms can be used to build intelligentindexes. Encapsulation could be violated by an image query, for example.One could provide a drawing or mug shot and the database would return suspects,or a picture of an airplane and the database could return the locationof all similar airplanes in recent satellite photos.

C++

C++ provides three levels of protection for data members and memberfunctions within a class. The default protection level is private.A private data memberor member function cannot be accessed by any function that is not a memberfunction of that class. The next level of protection is protected.A protected data memberor member function is accessible only to other member functions of thatclass or from classes derived from that class. The least restrictive levelof protection is public.public data members andmember functions can be accessed by any other function. The protectionlevel of data members and member functions is specified in the member declarationsusing the keywords public,protected, or private.

public members of aC++ base class do not automatically become publicmembers of the derived class; the base class must be explicitly declaredas public to allow this.

Specified non-member functions may be given access to private or protectedparts of classes. These functions are specified using the friendkeyword, and may be globally defined functions or members of other classes.Whole classes may be declared as friends of another class, in which caseevery member of the friend class can access the private members of thespecified class.

OOCOBOL

Objects may only be accessed through the operations defined in the object'sinterface. In defining an object, methods can be specified as PRIVATE,RESTRICTED, or PUBLIC. Data can be specified as PRIVATE or RESTRICTED (thereis no public data). If the scope of a data (method) name is declared asPRIVATE, this means that the data item (method) can be accessed (invoked)only from methods declared in the same class object or object definitionas the data item (method). If the scope of a data (method) name is declaredas RESTRICTED, this means that the data item (method) can be accessed (invoked)from methods declared in the same class object or object definition asthe data item (method), or from methods declared in a class object or objectrespectively that inherits from the class definition that contains thedeclaring class object or object definition. If the scope of a method nameis declared as PUBLIC, this means that the method can be invoked from anyprocedural statement that has access to an object identifier that may containthe class object or object of the class.

Smalltalk

The approach used in Smalltalk is to encapsulate all objects, whethera complex as a sorted list or as simple as a string, into a single programmingentity that includes data and logic. Further, other objects can not invokethe encapsulated data or logic. In order to interact, other objects mustsend messages to an object's interface that will cause the object to performa function that will have a known effect. See also entry under 2.3 Messages.

Eiffel

Features can only be invoked through the public interface of a class.A class's public interface consists of all operations and state that are`exported'. i.e., exported features are public and can be invoked by anyclass. A feature can also be exported to a select set of classes.

For example, a class may appear as follows:

Attributes a and b are exported to ANY (the parent of all classes) andtherefore all classes that are descendants of ANY. Attributes c and d arepublic to only classes A (the class itself), B and C. While attribute eis exported to no class (NONE).

Attributes (state) can be exported in a read-only form. This is differentto Smalltalk and other similar languages that cannot make state directlyaccessible to the public.

The implementation details of all operations are hidden in the publicinterface. Only the signature, an optional header comment and the pre-and postconditions are available in the public interface. Attributes andfunctions with no arguments also appear identical.

When inheriting there is no form of encapsulation. An inheritance relationshipinherits all features unconditionally. The exports status of inheritedfeatures is also inherited. However, this export status may be changed(with no restrictions) in the descendant. See also entry under 8. Inheritanceand Delegation.

Emerald

Object creation in Emerald is done via an object constructor,an Emerald expression that, when evaluated, creates a new object. Thisexpression defines the object's representation, and its public and privateoperations (an example is given in 2.9 communication model). Thesyntax of an object constructor is:

An export clause liststhe operations that can be called from outside the object; invocation ofone of these operations is the only way in which a client can examine ormodify the object's state. [RTLB+91] An object has only one interface,in the sense that there are no constructs that have special access to theobject. However, as noted under 7. Types and Classes, a client accessingan object via a variable will be restricted to performing the operationsdefined by the abstract type of the variable, even though the object assignedto the variable may support additional operations. In such cases, the variable'stype may in some sense be viewed as defining a different interface to theobject.

Cecil

Cecil supports a form of object encapsulation which merges aspects of"classical" object models with its own "generalized"object model capabilities. Fields and methods can be prefixed with publicor private declarationsthat effectively define an object's interface.

Intuitively, a private method is internal to the data abstraction implementation(s)of which it is a part, and only other methods also within the same implementation(s)can invoke that private method. More precisely, a sending method S is grantedaccess to a private method M only if S is considered part of the implementationof which M is also a part. A method is considered part of the implementationof an object if at least one of its formal arguments is specialized onthe object. Additionally, to deal with situations involving children accessingor overriding private methods which they inherit from their ancestors,a method is considered part of the implementation of an object if at leastone of its formal arguments is specialized on an ancestor or descendantof the object. A method that dispatches on more than one argument is consideredpart of the implementation of all dispatched arguments, and so is grantedprivileged access to each of them. (Note that, as described in the entryunder 2.6 state, fields resolve to pairs of methods, so access toboth state and behavior is covered by these rules.)

SELF

SELF as described in [US87] does not provide encapsulation, in the senseof having separate public and private interfaces. Any object can send amessage referencing any named slot, including assignment slots, containedwithin any other object. This sort of encapsulation could be provided throughsome technique for achieving the effect of private slots [probably withminimal impact on other key aspects of the language]. SELF, however, doesnot distinguish between accessing state and accessing behavior, and thusconceals this implementation issue from users.

System Object Model (SOM)

Access to the state of SOM objects is through the operations that makeup the objects interface. Invoking operations on SOM objects can have sideeffects. SOM objects do have private data that is not accessible by invokingexternal operations. In addition, it is possible to define class attributeson SOM objects. These attributes are accessed via set and get functionsimplemented for each attribute and are invoked in the same way as methods.

OLE Component Object Model

Objects may only be accessed through the operations defined in one ofthe object's interfaces. Moreover, given a reference to one interface,only the operations in that interface may be used. Operations in anotherinterface may only be used after first obtaining a reference to that interface.

Analysis and Design Methods

SD: "Note that in this architecturewe have defined the published interface of the class in terms of eventtakers [a kind of method], rather than the actions (or even processes thatmake up the action.) This provides true semantic encapsulation of the stateof an instance."

CA: "A principle, used when developingan overall program structure, that each component of a program should encapsulatea single design decision... The interface to each module is designed insuch a way as to reveal as little as possible about its inner workings.[quotedfrom The Oxford Dictionary of Computer Science]" The second sentencegives the sense used.

RA: "Encapsulation (also informationhiding) consists of separating the external aspects of an object [instance],which are accessible to other objects [instances], from the internal implementationdetails of the object, which are hidden from other objects."

JA: "The behavior and informationare encapsulated in the object [instance]. the only way to affect the objectis to perform operations on it. Objects thus support the concept of informationhiding, that is , they hide their internal structure from their surroundings."

WD: Encapsulation is "building ...a conceptual barrier around some collection of things. ... Encapsulationtransforms many into one by adding a new layer of meaning."

"The object has a public interfaceand a private representation, and keeps these two facets quite distinct.This principle is known as information hiding. Information-hiding allowsus to remove from view some portion [emphasis added--ed.]of those things which have been encapsulated by the object."

MD: "The information hiding principlemay be stated as follows: All information about a module should be privateto the module unless it is specifically declared to be public. " Incertain cases it is useful to hide a feature from all but one or a fewclasses.

EA: Apparently not used. Nothing in theanalysis model is hidden. There are no attributes. An objects may interactwith itself.

FD: "Data abstraction: The detailsof a classes representation are visible only to its methods."

OA: "... [E]ncapsulation providesa protective encasement around each object's data. The object's data becomesaccessible only by particular operations associated with the object."

BD: "Encapsulation is the processof compartmentalizing the elements of an abstraction that constitute itsstructure and behavior; encapsulation serves to separate the contractualinterface of an abstraction and its implementation." "Encapsulationis most often achieved through information hiding, which is the processof hiding all the secrets of an object that do not contribute to its essentialcharacteristics; typically, the structure of an object is hidden, as wellas the implementation of its methods."

HA: "At the implementation level,code and data can be encapsulated together into a class (i.e., gatheredtogether in a code module) yet remain visible to other classes. ... Onthe other hand, information hiding requires the visibility of data to berestricted to within the (encapsulated) module. In other words, encapsulationdoes not guarantee information hiding. Similarly, information hiding doesnot necessitate encapsulation of the concept in a module. In OT the aimis to use both mechanisms to encapsulate a concept within one module andto hide the details of that concept's implementation via information hiding."

NA: "Information hiding[:] A techniquewhereby implementation details ... are hidden from the authors of clientmodules, who are instead presented with a public interface."


features matrixintro page