In [[object-oriented programming]] (OOP), '''encapsulation''' refers to the bundling of data with the methods that operate on that data., Often that definition is misconstrued to mean thator the datarestricting isof somehowdirect hidden.access Into Java,some youof canan haveobject's encapsulated data that is not hidden at allcomponents. So '''encapsulation''' and '''hiding''' are not the same and have different meaning! <ref name="Rogers01" /> Encapsulation is used to closehide (inthe meaningvalues containing)or the structurestate of a structured data object inside a [[Class (computer programming)|class]], preventing direct access to them (inby meaning:clients you can not use any member ofin a classway withoutthat thecould classexpose mention,hidden e.g.implementation ifdetails someor classviolate Astate hasinvariance xmaintained fieldby youthe couldmethods. not use this field x without class A or their instance).
Publicly accessible methods are generally provided in the class to access or modify the state more abstractly. In practice sometimes methods (so-called [[Mutator method|"getters" and "setters"]]) are provided to access the values indirectly, but, although not necessarily a violation of abstract encapsulation, they are often considered a sign-post of potentially poor object-oriented programming (OOP) design practice <ref>{{cite web |url=https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html |title=Why Getter and Setter methods are evil |last=Holub |first=Allen |publisher=JavaWorld |date=September 5, 2003 |website=Info World |archive-url=https://web.archive.org/web/20200729073721/https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html |access-date=January 17, 2021|archive-date=2020-07-29 }}</ref> (an [[Anti-pattern]]).
This mechanism is not unique to OOP. Implementations of [[abstract data types]], e.g., [[module (programming)|modules]], offer a similar form of encapsulation. The similarity has been explained by programming language theorists in terms of [[existential types]].<ref>{{harvnb|Pierce|2002|loc=§ 24.2 Data Abstraction with Existentials}}</ref>
