Encapsulation vs Information hiding
Well I know that making fields private and then making setter and getter of the fields is encapsulation. However, does encapsulation mean just this?
---> Encapsulation is an OOP concept where object state(class fields) and it's behaviour(methods) is wrapped together. Java provides encapsulation using class.
Information Hiding:
--> mechanism for restricting access to some of the object's components. Your above example is the case of Information Hiding if you make age private.
Initially, Information/Data Hiding was considered the part of Encapsulation, and the definitions of Encapsulation would be as:
- A language mechanism for restricting access to some of the object's components.
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
the second definition is motivated by the fact that in many OOP languages hiding of components is not automatic or can be overridden; thus, information hiding is defined as a separate notion by those who prefer the second definition.
Reference: wikipage
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 (1971) 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 robustness. 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.
From abstraction-vs-information-hiding-vs-encapsulation
Abstraction and encapsulation are complementary concepts: abstraction focuses on the observable behavior of an object... encapsulation focuses upon the implementation that gives rise to this behavior... encapsulation is most often achieved through information hiding, which is the process of hiding all of the secrets of object that do not contribute to its essential characteristics.
Information Hiding:
"Its interface or definition was chosen to reveal as little as possible about its inner workings." — [Parnas, 1972b]
"Abstraction can be […] used as a technique for identifying which information should be hidden."
"Confusion can occur when people fail to distinguish between the hiding of information, and a technique (e.g., abstraction) that is used to help identify which information is to be hidden."
Encapsulation:
"It […] refers to building a capsule, in the case a conceptual barrier, around some collection of things." — [Wirfs-Brock et al, 1990]
"As a process, encapsulation means the act of enclosing one or more items within a […] container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items."
"If encapsulation was 'the same thing as information hiding,' then one might make the argument that 'everything that was encapsulated was also hidden.' This is not obviously not true."