Encapsulation (object-oriented programming)

As data encapsulation (English encapsulation, according to David Parnas also known as information hiding ) is called in the programming data hiding or information against access from outside. The direct access to the internal data structure is suppressed and instead takes place through defined interfaces (black box model).

Derivation

Data encapsulation is a long -known concept within the structured and modular programming. Heart of the model here is the abstract data type in which data are summarized in a data structure can be accessed only via defined access functions (procedures). In actual programming of abstract data type is implemented in various ways.

Another example in modern programming languages is the hiding of data within scopes. Each sub- structure of a program ( main block, procedures, functions, subroutines, ... ) defines such a region, so that a validity hierarchy is created. Declared data are visible and only valid within the surrounding and in all the deeper areas; for a higher range, they remain hidden.

Data encapsulation in object-oriented paradigm

Encapsulation is also an important concept of object-oriented programming. When encapsulation is called controlled access to methods and attributes of classes. Classes can not read or change in unexpected ways the internal state of other classes. A class has an interface, which determines about may be the way in which interacts with the class. This prevents the circumvention of invariants of the program. From the inner workings of a class of users is - both the algorithms that work with the class, as well as the programmer who developed this meant are - need to know as little as possible ( information hiding ). By encapsulating only information about the "what" ( operation ) of a class are visible to the outside, but not the "how" ( the internal representation ). This defines the outside and at the same time a documented interface.

Access types used

The UML as a de facto standard notation allows to model the following types of access (in brackets the shorthand notation of UML):

Note: The handling of the keyword package is different in the various programming or scripting languages. Replacement in the language:

C #: internal
Visual Basic NET. Friend
Java: No definition is package access (default).

The options for specifying the accessibility vary by programming language.

Benefits

Implementation of a class as the other classes is not known, the implementation may be changed without affecting the cooperation with other classes.
Increased transparency, as only the public interface of a class must be considered.
When accessing an access function plays from the outside no matter whether this function 1:1 exists inside the class, the result of a calculation, or possibly from other sources ( such as a file or database) is derived.
Significantly improved testability, stability and changeability of software or its components ( modules).
Reducing the number of possible adverse interactions between parts of the program. If a program contains N variables and M functions, there are potential interactions; but usually only interactions are actually desirable. This plays a role in troubleshooting because most errors thereby manifest that a variable contains an incorrect value, and you need to know to isolate the cause of which have functions on the variable access; data encapsulation restricts the program section to be examined from the outset a very few functions.

Disadvantages

Depending on the application, speed penalty by calling accessor functions (direct access to the data elements would be faster ).
Additional programming effort for the creation of access functions.

Single Responsibility | Open Closed | liskovsches substitution principle | Interface Segregation | Dependency Inversion

Programming concept

Invariant (computer science) Open/closed principle Interface segregation principle

219824