In software systems, encapsulation refers to the bundling of data with the mechanisms or methods that operate on the data, or the limiting of direct access to some data, such as an object's components.
[ Encapsulation allows developers to present a consistent and usable interface which is independent of how a system is implemented internally. As one example, encapsulation can be used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods.
All object-oriented programming (OOP) systems support encapsulation, but encapsulation is not unique to OOP. Implementations of abstract data types, modules, and libraries, among other systems, also offer encapsulation. The similarity has been explained by programming language theorists in terms of existential types.
]
Meaning
In object-oriented programming languages, and other related fields, encapsulation refers to one of two related but distinct notions, and sometimes to the combination thereof:
* A language mechanism for restricting direct access to some of the object's components.
* A language construct that facilitates the bundling of data with the methods (or other functions) operating on those data.
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 lexical closures view encapsulation as a feature of the language orthogonal
In mathematics, orthogonality is the generalization of the geometric notion of ''perpendicularity''.
By extension, orthogonality is also used to refer to the separation of specific features of a system. The term also has specialized meanings in ...
to object orientation.
The second definition is motivated by the fact 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.
The features of encapsulation are supported using classes in most object-oriented languages, although other alternatives also exist.
Encapsulation and inheritance
The authors of ''Design Patterns
''Design Patterns: Elements of Reusable Object-Oriented Software'' (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword ...
'' discuss the tension between 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. As described by the yo-yo problem In software development, the yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different cla ...
, overuse of inheritance and therefore encapsulation, can become too complicated and hard to debug.
Information hiding
Under the definition that encapsulation "can be used to hide data members and member functions", the internal representation of an 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. 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, by allowing the developer to limit the interdependencies between software components.
Some languages like Smalltalk
Smalltalk is an object-oriented, dynamically typed reflective programming language. It was designed and created in part for educational use, specifically for constructionist learning, at the Learning Research Group (LRG) of Xerox PARC by Alan Ka ...
and Ruby only allow access via object methods, but most others (e.g., C++, C#, Delphi
Delphi (; ), in legend previously called Pytho (Πυθώ), in ancient times was a sacred precinct that served as the seat of Pythia, the major oracle who was consulted about important decisions throughout the ancient classical world. The oracle ...
or Java) offer the programmer a degree of control over what is hidden, typically via keywords like public
and private
.[ ISO C++ standard refers to ]protected
, private
and public
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.
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), or special keyword usage like friend
in C++. Systems that provide object-level capability-based security (adhering to the object-capability model) are an exception, and guarantee strong encapsulation.
Examples
Restricting data fields
Languages like C++, C#, Java, PHP, Swift, and Delphi
Delphi (; ), in legend previously called Pytho (Πυθώ), in ancient times was a sacred precinct that served as the seat of Pythia, the major oracle who was consulted about important decisions throughout the ancient classical world. The oracle ...
offer ways to restrict access to data fields.
Below is an example in C# that shows how access to a data field can be restricted through the use of a private
keyword:
class Program
Below is an example in Java:
public class Employee
Encapsulation is also possible in non-object-oriented languages. In C, for example, a structure can be declared in the public API via the header file for a set of functions that operate on an item of data containing data members that are not accessible to clients of the API with the extern
keyword.
// Header file "api.h"
struct Entity; // Opaque structure with hidden members
// API functions that operate on 'Entity' objects
extern struct Entity * open_entity(int id);
extern int process_entity(struct Entity *info);
extern void close_entity(struct Entity *info);
// extern keywords here are redundant, but don't hurt.
// extern defines functions that can be called outside the current file, the default behavior even without the keyword
Clients call the API functions to allocate, operate on, and deallocate objects of an opaque data type. The contents of this type are known and accessible only to the implementation of the API functions; clients cannot directly access its contents. The source code for these functions defines the actual contents of the structure:
// Implementation file "api.c"
#include "api.h"
struct Entity ;
// API function implementations
struct Entity * open_entity(int id)
int process_entity(struct Entity *info)
void close_entity(struct Entity *info)
Name mangling
Below is an example of Python, which does not support variable access restrictions. However, the convention is that a variable whose name is prefixed by an underscore should be considered private.
class Car:
def __init__(self) -> None:
self._maxspeed = 200
def drive(self) -> None:
print(f"Maximum speed is .")
redcar = Car()
redcar.drive() # This will print 'Maximum speed is 200.'
redcar._maxspeed = 10
redcar.drive() # This will print 'Maximum speed is 10.'
See also
* Inheritance (object-oriented programming)
* Object-oriented programming
* Software design pattern
* Facade pattern
References
{{Reflist
Object-oriented programming
Articles with example Java code