Encapsulation and information hiding are very closely linked concepts, though their precise definitions vary depending on who you talk to.
The concept of “information hiding” was first described by Parnas (1972) who suggested that access to information should be restricted to reduce the interconnectedness of a system. He proposed that this would facilitate splitting of a system into modules while maintaining a user-friendly external interface and allowing implementation details to be changed without affecting clients.
The term “encapsulation” was coined by Zilles (1973) to describe the use of procedures to control access to underlying data in order to reduce system complexity and protect data from dangerous modification.
Subsequently, Parnas (1978) described information hiding and encapsulation (and abstraction) as synonymous terms, which describe the hiding of details of a system that are likely to change. However, distinctions have been drawn between information hiding and encapsulation, such as by Micallef (1987), who described encapsulation as “the strict enforcement of information hiding”. Some authors, such as Cohen (1984) and Abreu and Melo (1996) describe “encapsulation mechanisms”, especially in object-oriented programming languages, as allowing information hiding.
Meyers (2000) suggests that the degree to which a piece of code is encapsulated depends on the amount of code which would be broken if it changed. In this sense, private data and methods are more encapsulated the fewer methods by which they can be accessed. In contrast, public data and methods are completely unencapsulated, as the amount of code by which they can be accessed is unknown.
Conversely, Rogers (2001) suggests that encapsulation is simply the language mechanism that allows data to be bundled with methods that operate on that data. He claims that encapsulation fundamentally has nothing to do with information hiding. However, this definition is counter to almost all usage of the term in the academic literature in the 28 years prior to the publication of his article. There are a few other examples of this usage, for example Archer and Stinson (1995), but they are few and far between and not particularly notable.
In conclusion, information hiding is the idea that information should be hidden so that a design can be changed without affecting clients. This allows for increased flexibility and safety. Encapsulation may be considered to be the same as information hiding, but the term is often used to describe the practical implementation of information hiding, especially in object-oriented programming.
As an example of information hiding/encapsulation, consider this class:
public class BankAccount {
public int dollars;
}
The implementation of this class is completely unencapsulated, which means it is inflexible (e.g. we cannot easily add support for individual cents in the future) and unsafe (e.g. the account can changed to be negative). However, if we hide the data behind a formally defined interface of methods, we gain flexibility and safety.
public class BankAccount {
private int dollars;
public void deposit(int dollars) {
this.dollars += Math.max(0, dollars);
}
}
We now have control over how the state is modified, and we can also change the implementation without breaking client code:
public class BankAccount {
private int cents;
public void deposit(int dollars) {
deposit(dollars, 0);
}
public void deposit(int dollars, int cents) {
this.cents += Math.max(0, 100 * dollars) + Math.max(0, cents);
}
}
The class is now better encapsulated because we have hidden information about its underlying implementation.