Editing Encapsulation (computer programming) (section)

== Meaning ==
In [[object-oriented programming languages]], and other related fields, <!-- [[object-oriented programming language]]--> <!-- and related fields, like [[OODMBS]],--> encapsulation refers to one of two related but distinct notions, and sometimes to the combination thereof:<ref>{{cite book |first=Michael Lee |last=Scott |title=Programming language pragmatics |edition= 2 |publisher=Morgan Kaufmann |year=2006 |isbn=978-0-12-633951-2 |page=481 |quote=Encapsulation mechanisms enable the programmer to group data and the subroutines that operate on them together in one place, and to hide irrelevant details from the users of an abstraction}}</ref><ref name="Dale">{{cite book |first1=Nell B. |last1=Dale |first2=Chip |last2=Weems |title=Programming and problem solving with Java |edition= 2nd |publisher=Jones & Bartlett |year=2007 |isbn=978-0-7637-3402-2 |page=396}}</ref>

* A language mechanism for restricting direct access to some of the [[object (computer science)|object]]'s components.<ref>{{cite book |author-link=John C. Mitchell |first=John C. |last=Mitchell |title=Concepts in programming languages |publisher=Cambridge University Press |year=2003 |isbn=978-0-521-78098-8 |page=522}}</ref><ref name=Pierce>{{cite book |last=Pierce |first=Benjamin |author-link=Benjamin C. Pierce |title=Types and Programming Languages |publisher=MIT Press |year=2002 |isbn=978-0-262-16209-8 |page=266 |title-link=Types and Programming Languages }}</ref>
* A language construct that facilitates the bundling of data with the [[method (computer programming)|method]]s <!-- I object to the word method being used here because in lisp languages programmers cannot distinguish methods from normal functions at the [[call site]].  Behavior equivalent to methods may be implemented as normal functions. encapsulation is not dependent on implementation but on behavior--> (or other functions) operating on those data.<ref name=Rogers01>{{cite web |last1=Rogers |first1=Wm. Paul |date=2001-05-18 |df=dmy |url=https://www.infoworld.com/article/2075271/encapsulation-is-not-information-hiding.html |title=Encapsulation is not information hiding |work=[[JavaWorld]] |access-date=2020-07-20}}</ref><ref>{{cite book |first1=Thomas M. |last1=Connolly |first2=Carolyn E. |last2=Begg |title=Database systems: a practical approach to design, implementation, and management |edition=  4th |publisher=Pearson Education |year=2005 |isbn=978-0-321-21025-8 |chapter=Ch. 25: Introduction to Object DMBS § Object-oriented concepts |page=814}}</ref>

Some programming language researchers and academics use the first meaning alone or in combination with the second as a distinguishing feature of [[object-oriented programming]], while some programming languages that provide [[closure (computer programming)|lexical closures]] view encapsulation as a feature of the language [[orthogonality#Computer science|orthogonal]] to object orientation.

The second definition reflects that in many object-oriented languages, and other related fields, the components are not hidden automatically and this can be overridden. Thus, [[information hiding]] is defined as a separate notion by those who prefer the second definition.<!-- this is based on all the refs given above, so no inline cite here-->

The features of encapsulation are supported using [[class (computer programming)|class]]es in most object-oriented languages, although other alternatives also exist.

Encapsulation may also refer to containing a repetitive or complex process in a single unit to be invoked. Object-oriented programming facilitate this at both the method and class levels. This definition is also applicable to [[procedural programming]].<ref>{{Cite book |last=McDonough |first=James E. |title=Object-Oriented Design with ABAP: A Practical Approach |publisher=[[Apress]] |year=2017 |isbn=978-1-4842-2837-1 |location= |chapter=Encapsulation |doi=10.1007/978-1-4842-2838-8 |via=[[O'Reilly Media|O'Reilly]]}}</ref>

=== Encapsulation and inheritance ===
The authors of ''[[Design Patterns]]'' discuss the tension between [[inheritance (object-oriented programming)|inheritance]] and encapsulation at length and state that in their experience, designers overuse inheritance. They claim that inheritance often breaks encapsulation, given that inheritance exposes a subclass to the details of its parent's implementation.<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            = 978-0-201-63361-0| url-access            = registration
| url            = https://archive.org/details/designpatternsel00gamm
}}</ref> As described by the [[yo-yo problem]], overuse of inheritance and therefore encapsulation, can become too complicated and hard to debug.