Content deleted Content added
No edit summary |
m ISBNs (Build J/) |
||
Line 1:
In a programming language, <!-- [[object-oriented programming language]]--> <!-- and related fields, like [[OODMBS]],--> '''encapsulation''' is used to refer to one of two related but distinct notions, and sometimes to the combination<ref>Michael Lee Scott, ''Programming language pragmatics'', Edition 2, Morgan Kaufmann, 2006, ISBN
* A language mechanism for restricting access to some of the [[object (computer science)|object]]'s components.<ref>[[John C. Mitchell]], ''Concepts in programming languages'', Cambridge University Press, 2003, ISBN
* A language construct that facilitates the bundling of data with the methods <!-- 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 that data.<ref>Wm. Paul Rogers, [http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html?page=9 ''Encapsulation is not information hiding''], JavaWorld.com, 05/18/01</ref><ref>Thomas M. Connolly, Carolyn E. Begg, ''Database systems: a practical approach to design, implementation, and management'', Edition 4, Pearson Education, 2005, ISBN
Some programming language researchers and academics use the first meaning alone or in combination with the second as a [[Object oriented programming#features|distinguishing feature of object oriented programming]], while other programming languages which provide [[Closure (computer programming)|lexical closures]] view encapsulation as a feature of the language orthogonal to object orientation.
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.<!-- this is based on all the refs given above, so no inline cite here-->
Line 13:
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 benefit of encapsulation is that it can reduce system complexity, and thus increases [[robustness (computer science)|robustness]], by allowing the developer to limit the interdependencies between software components.
Almost always, there is a way to override such protection - usually via reflection API (Ruby, Java, C#, etc.), sometimes by mechanism like name mangling ([[Python (programming language)|Python]]), or special keyword usage like <code>friend</code> in C++.
== General Definition ==
Line 24:
{{Expand section|date=December 2009}}
With regards to combination (or bundling) data, this is prevalent in any object that is created. An object's state will depend on its methods that do work on or with the object's internal data.
An analogy can be made here with the notion of a [[Information hiding|capsule]], which not only encloses its contents, but also protects it from the exterior environment.<ref name=Dale/>
|