Encapsulation Definition

Candidate Definitions for Encapsulation:

Physically grouping together related operations or things.

Gate Keeper of state or data.

Hiding implementation.

In programming, the process of combining elements to create a new entity. For example, a procedure is a type of encapsulation because it combines a series of computer instructions. Likewise, a complex data type, such as a record or class, relies on encapsulation. Object Oriented Programming Languages rely heavily on encapsulation to create high-level objects. Encapsulation is closely related to abstraction and information hiding.

Encapsulation is a word that gets bandied about a lot in discussions on wiki, and it almost always is being misused as a synonym for abstraction or information hiding. (I do it too.)

To give a concrete example of the differences:

a java interface provides an abstraction.

implementations of this interface which do not exposed any other methods are employing information hiding; we cannot tell how they are implemented.

if the implementation exposes multiple methods, it is employing encapsulation.

In the strictest OO sense of the term, encapsulation is gathering all operations on the object's state into the object's interface, and only those operations. This is one sense in which you can talk about 'enforcing encapsulation'. The other is that methods can only operate on the state of their own object (which implies that other objects in the system employ information hiding).

Another example, Perl's OO syntax allows for encapsulation, but does not provide full information hiding - you can access any part of an objects data, to any depth. Emacs Lisp is a language with very little encapsulation - functions and data are often independent and freestanding. In the Self Language method definitions (that would in normal OO be part of the class) are placed in 'traits' objects; objects delegate manipulations of themselves to the traits object (ie encapsulation is broken, deliberately).

Erm, not to be picky, but Perl does allow for information hiding, it just doesn't do it by default. See Information Hiding In Perl for my description of how to do it. -- Jeff Bay

Mostly when we associate encapsulation with OO, we mean that languages provide support for it, not that they enforce it (a claim made for Component Oriented Programming that probably meant information hiding).

Examples of ways to break (strict) encapsulation:

Utility classes, containing unrelated methods whose return value is a function only of their inputs. e.g. Math.sin(x) in java. (Strict encapsulation would lead to x.sin())

Operations on streams (usually achieved with a pipline of objects, each of which is responsible for some of the manipulation of the stream 'state'. (Strict encapsulation may well be achievable in this case, but doesnt lead to reusable code)

Hopefully the message is getting through: encapsulation is not information hiding, and is not necessarily an unequivocal force for good, especially in its strictest sense.

Information hiding is more often pure natural goodness, allowing you to work with layered architectures, component frameworks, and all that jazz. I'm curious if anyone can provide examples Where Information Hiding Isa Bad Thing. (whoops just thought of one. optimizing code has a tendency to break IH - accessing members is faster than accessing methods)

In Java, directly accessing class attributes is often slower than assigning an accessor's return value to a local variable, then using the local variable. JVMs use a longer bytecode for instance variables than local variables. Lest you argue assigning a local variable directly to an instance variable, keep in mind that the compiler will likely inline the call to the accessor, thus allowing the code to maintain its speed without breaking encapsulation*.

Before you mess with information hiding, use a profiler to make sure you are changing the sluggish part of your code! I very much doubt the techniques used in proper information hiding result in poorly performing code.

*Yes, encapsulation. Accessors hide how the data is derived. Information Hiding prevents external objects from using the derived data altogether.

I would say that encapsulation is complexity hiding. -- Nikita Belenki

Using "complexity" usually does not make for very good definitions.

Asking the question 'What is encapsulation?' and receiving the answer 'It's about marking methods/fields as private', is generally an indication that although the programmer is using classes and objects, it doesn't mean that they are using OO.

I am currently looking at a class which takes some parameters in its 2 public constructors, then calls back to a private constructor (breaking what to me is the very important rule of Constructor Least To Most), and then in the two public methods calls a private method called postConstuction, which starts a cascading chain of calling seven other private methods. I am currently investigating how the results of this procedural beauty are collected. Of course, the class is Well Encapsulated because it's methods are private!

Sorry ,

-- Shaun Smith

From the Naked Objects book:

The word has two meanings in English. The first has to do with being sealed, as in a medicinal capsule or a time capsule. This is how many people use it in the context of object-orientation: an object is sealed by a message-interface, with the internal implementation hidden from view. This is an important property of objects, but it is not unique to them. The ideas of black-box operation and of 'information hiding' are common to many forms of component-based systems development. The second meaning of encapsulation is that something exemplifies the essential features of something else, as in 'this document encapsulates our marketing strategy'. This second meaning - which corresponds to the principle of behavioural completeness - is far more important in the context of object-oriented modelling.

As far as the IT industry goes, there are at least two kinds of encapsulation, Clear Encapsulation and Obscure Encapsulation. It makes life a lot easier when predecessors have arrived at Clear Encapsulation. -- Peter Lynch