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-->
g gk uh
== As information hiding mechanism ==
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++]] 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>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 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++.
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 fundament of an [[existential type]].<ref>Pierce (2002), Section 24.2 "Data Abstraction with Existentials"</ref>
