Object-Orientation FAQ

[Booch 91, p. 45] defines: "Encapsulation is the process of hiding all of the
details of an object that do not contribute to its essential characteristics."

[Coad 91, 1.1.2] defines: "Encapsulation (Information Hiding).  A principle,
used when developing an overall program structure, that each component of a
program should encapsulate or hide a single design decision...  The interface
to each module is defined in such a way as to reveal as little as possible
about its inner workings.  [Oxford, 1986]"

Some languages permit arbitrary access to objects and allow methods to be
defined outside of a class as in conventional programming.  Simula and
Object Pascal provide no protection for objects, meaning instance variables
may be accessed wherever visible.  CLOS and Ada allow methods to be defined
outside of a class, providing functions and procedures.  While both CLOS
and Ada have packages for encapsulation, CLOS's are optional while Ada's
methodology clearly specifies class-like encapsulation (Adts).

However most object-oriented languages provide a well defined interface to
their objects thru classes.  C++ has a very general encapsulation/protection
mechanism with public, private and protected members.  Public members (member
data and member functions) may be accessed from anywhere.  A Stack's Push and
Pop methods will be public.  Private members are only accessible from within
a class.  A Stack's representation, such as a list or array, will usually be
private.  Protected members are accessible from within a class and also from
within subclasses (also called derived classes).  A Stack's representation
could be declared protected allowing subclass access.  C++ also allows a
class to specify friends (other (sub)classes and functions), that can access
all members (its representation).  Eiffel 3.0 allows exporting access to
specific classes.

For another example, Smalltalk's class instance variables are not accessible
from outside of their class (they are not only private, but invisible).
Smalltalk's methods are all public (can be invoked from anywhere), but a
private specifier indicates methods should not be used from outside of the
class.  All Smalltalk instance variables can be accessed by subclasses,
helping with abstract classes and overriding.

Another issue is per-object or per-class protection.  Per-class protection
is most common (e.g. Ada, C++, Eiffel), where class methods can access any
object of that class and not just the receiver.  Methods can only access the
receiver in per-object protection.  This supports a subtyping model, as any
object other than the receiver is only satisfying an abstract type interface,
whereby no method or object structure can be inferred in the general case.