Encapsulation (computer programming): Difference between revisions

Revision as of 07:55, 22 July 2016

Revision as of 16:50, 1 October 2016

Line 12:

== An information-hiding mechanism ==

{{See also|Information hiding}}

{{em| Encapsulation can be used to hide data members and members function.}} Under this definition, encapsulation means that the internal representation of an [[object (computer science)|object]] is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Some languages like [[Smalltalk]] and [[Ruby (programming language)|Ruby]] only allow access via object methods, but most others (e.g. [[C++]], [[C Sharp (programming language)|C#]] or [[Java (programming language)|Java]]) offer the programmer a degree of control over what is hidden, typically via keywords like <code>public</code> and <code>private</code>.<ref name=Pierce/> It should be noted that the ISO C++ standard refers to <code>protected</code>, <code>private</code> and <code>public</code> as "[[access specifiers]]" and that they do not "hide any information". Information hiding is accomplished by furnishing a compiled version of the source code that is interfaced via a header file.

Encapsulation can be used to hide data members and members function...

Under this definition, encapsulation means that the internal representation of an [[object (computer science)|object]] is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Some languages like [[Smalltalk]] and [[Ruby (programming language)|Ruby]] only allow access via object methods, but most others (e.g. [[C++]], [[C Sharp (programming language)|C#]] or [[Java (programming language)|Java]]) offer the programmer a degree of control over what is hidden, typically via keywords like <code>public</code> and <code>private</code>.<ref name=Pierce/> It should be noted that the ISO C++ standard refers to <code>protected</code>, <code>private</code> and <code>public</code> as "[[access specifiers]]" and that they do not "hide any information". Information hiding is accomplished by furnishing a compiled version of the source code that is interfaced via a header file.

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A supposed benefit of encapsulation is that it can reduce system complexity, and thus increase [[robustness (computer science)|robustness]], by allowing the developer to limit the inter-dependencies between software components{{Citation needed|date=April 2014}}.

Line 164 ⟶ 163:

In general, encapsulation '''is one of the four fundamentals''' of OOP ([[object-oriented programming]]). Encapsulation refers to the bundling of data with the methods that operate on that data.<ref>{{cite web|last=Rodgers|first=Wm. Paul|title=Encapsulation is not information hiding|url=http://www.javaworld.com/article/2075271/core-java/encapsulation-is-not-information-hiding.html|publisher=JavaWorld|accessdate=2014-03-15}}</ref> Encapsulation is '''used to hide the values or state of a structured data object inside a class''', preventing unauthorized parties' direct access to them. Publicly accessible methods are generally provided in the class (so-called ''getters'' and ''setters'') to access the values, and other client classes call these methods to retrieve and modify the values within the object.

This mechanism is not unique to object-oriented programming. Implementations of [[abstract data types]], e.g. [[module (programming)|modules]], offer a similar form of encapsulation. This similarity stems from the fact that both notions rely on the same mathematical fundamentfundamental of an [[existential type]].<ref>Pierce (2002), Section 24.2 "Data Abstraction with Existentials"</ref>

== Encapsulation and Inheritance ==

The authors of Design Patterns<ref name="GoF">

{{cite book

| last1 = Gamma

| first1 = Erich

| last2 = Helm

| first2 = Richard

| last3 = Johnson

| first3 = Ralph

| last4 = Vlissides

| first4 = John

| title = Design Patterns

| date = 1994

| publisher = Addison-Wesley

| isbn = 0-201-63361-2

}}</ref> discuss the tension between inheritance and encapsulation at length and state that in their experience, designers overuse inheritance. The danger is stated as follows:

{{quote |text=Because inheritance exposes a subclass to details of its parent's implementation, it's often said that "inheritance breaks encapsulation" |author=Gang of Four |source=Design Patterns<ref name="GoF" /> (Chapter 1)}}

== References ==