En los sistemas de software, la encapsulación se refiere a la agrupación de datos con los mecanismos o métodos que operan sobre los datos. También puede referirse a la limitación del acceso directo a algunos de esos datos, como los componentes de un objeto. [1] Esencialmente, la encapsulación evita que el código externo se preocupe por el funcionamiento interno de un objeto.
La encapsulación permite a los desarrolladores presentar una interfaz consistente que es independiente de su implementación interna. Como ejemplo, la encapsulación se puede utilizar para ocultar los valores o el estado de un objeto de datos estructurados dentro de una clase . Esto evita que los clientes accedan directamente a esta información de una manera que pueda exponer detalles de implementación ocultos o violar la invariancia de estado mantenida por los métodos.
La encapsulación también anima a los programadores a colocar todo el código relacionado con un determinado conjunto de datos en la misma clase, lo que lo organiza para que otros programadores lo comprendan fácilmente. La encapsulación es una técnica que fomenta el desacoplamiento .
Todos los sistemas de programación orientada a objetos (POO) admiten la encapsulación, [2] [3] pero la encapsulación no es exclusiva de la POO. Las implementaciones de tipos de datos abstractos , módulos y bibliotecas también ofrecen encapsulación. La similitud ha sido explicada por los teóricos del lenguaje de programación en términos de tipos existenciales . [4]
En los lenguajes de programación orientados a objetos y otros campos relacionados, la encapsulación se refiere a una de dos nociones relacionadas pero distintas y, a veces, a la combinación de las mismas: [5] [6]
Algunos investigadores y académicos de lenguajes de programación utilizan el primer significado solo o en combinación con el segundo como una característica distintiva de la programación orientada a objetos , mientras que algunos lenguajes de programación que proporcionan cierres léxicos ven la encapsulación como una característica del lenguaje ortogonal a la orientación a objetos.
La segunda definición refleja que en muchos lenguajes orientados a objetos y otros campos relacionados, los componentes no se ocultan automáticamente y esto se puede anular. Por lo tanto, quienes prefieren la segunda definición definen el ocultamiento de información como una noción separada.
Las funciones de encapsulación se admiten mediante clases en la mayoría de los lenguajes orientados a objetos, aunque también existen otras alternativas.
Los autores de Design Patterns analizan extensamente la tensión entre herencia y encapsulación y afirman que, según su experiencia, los diseñadores abusan de la herencia. Afirman que la herencia a menudo rompe la encapsulación, dado que la herencia expone una subclase a los detalles de la implementación de su padre. [10] Como se describe en el problema yo-yo , el uso excesivo de la herencia y, por lo tanto, la encapsulación, puede volverse demasiado complicado y difícil de depurar.
Según la definición de que la encapsulación "puede usarse para ocultar miembros de datos y funciones miembro", la representación interna de un objeto generalmente está oculta fuera de la definición del objeto. Normalmente, sólo los propios métodos del objeto pueden inspeccionar o manipular directamente sus campos. Ocultar las partes internas del objeto protege su integridad al evitar que los usuarios establezcan los datos internos del componente en un estado no válido o inconsistente. Un supuesto beneficio de la encapsulación es que puede reducir la complejidad del sistema y, por tanto, aumentar la robustez , al permitir al desarrollador limitar las interdependencias entre los componentes del software. [ cita necesaria ]
Algunos lenguajes como Smalltalk y Ruby sólo permiten el acceso a través de métodos de objetos, pero la mayoría de los demás (por ejemplo, C++ , C# , Delphi o Java [11] ) ofrecen al programador cierto control sobre lo que está oculto, normalmente mediante palabras clave como publicy private. [8] El estándar ISO C++ se refiere a protectedy privatecomo public" especificadores de acceso " y que no "ocultan ninguna información". La ocultación de información se logra proporcionando una versión compilada del código fuente que se interconecta a través de un archivo de encabezado.
Casi siempre, hay una manera de anular dicha protección, generalmente mediante API de reflexión (Ruby, Java, C#, etc.), a veces mediante mecanismos como la alteración de nombres ( Python ) o el uso de palabras clave especiales como frienden C++. Los sistemas que proporcionan seguridad basada en capacidades a nivel de objetos (que se adhieren al modelo de capacidad de objetos ) son una excepción y garantizan una encapsulación sólida.
Lenguajes como C++ , C# , Java , [11] PHP , Swift y Delphi ofrecen formas de restringir el acceso a los campos de datos.
A continuación se muestra un ejemplo en C# que muestra cómo se puede restringir el acceso a un campo de datos mediante el uso de una privatepalabra clave:
programa de clase { cuenta de clase pública { saldo de cuenta decimal privado = 500,00 m ; saldo de cuenta decimal público () { return _accountBalance ; } } static void Main () { Cuenta miCuenta = nueva Cuenta (); decimal miSaldo = miCuenta . ComprobarSaldo (); /* Este método principal puede verificar el saldo a través del * método público "CheckBalance" proporcionado por la clase "Account" * pero no puede manipular el valor de "accountBalance" */ } } A continuación se muestra un ejemplo en Java :
Empleado de clase pública { salario BigDecimal privado = nuevo BigDecimal ( 50000,00 ); public BigDecimal getSalary () { devuelve esto . salario ; } public static void main () { Empleado e = nuevo Empleado (); BigDecimal sal = e . obtenerSalario (); } } La encapsulación también es posible en lenguajes no orientados a objetos. En C , por ejemplo, se puede declarar una estructura en la API pública a través del archivo de encabezado para un conjunto de funciones que operan en un elemento de datos que contiene miembros de datos a los que no pueden acceder los clientes de la API con la externpalabra clave. [12]
// Archivo de encabezado "api.h"estructura Entidad ; // Estructura opaca con miembros ocultos // Funciones API que operan en objetos 'Entidad' extern struct Entity * open_entity ( int id ); extern int proceso_entidad ( estructura Entidad * información ); extern void close_entity ( estructura Entidad * información ); // Las palabras clave externas aquí son redundantes, pero no hacen daño. // externo define funciones que se pueden llamar fuera del archivo actual, el comportamiento predeterminado incluso sin la palabra clave Los clientes llaman a las funciones API para asignar, operar y desasignar objetos de un tipo de datos opacos . Los contenidos de este tipo son conocidos y accesibles únicamente para la implementación de las funciones API; los clientes no pueden acceder directamente a sus contenidos. El código fuente de estas funciones define el contenido real de la estructura:
// Archivo de implementación "api.c"#incluir "api.h" estructura Entidad { int ent_id ; // número de ID char ent_name [ 20 ]; // Nombre ... y otros miembros ... }; // implementaciones de funciones API struct Entity * open_entity ( int id ) { ... } int entidad_proceso ( estructura Entidad * información ) { ... } void close_entity ( estructura Entidad * información ) { ... } A continuación se muestra un ejemplo de Python , que no admite restricciones de acceso a variables. Sin embargo, la convención es que una variable cuyo nombre tiene como prefijo un guión bajo debe considerarse privada. [13]
clase Coche : def __init__ ( self ) -> Ninguno : self . _velocidad máxima = 200 def drive ( self ) -> Ninguno : print ( f "La velocidad máxima es { self . _maxspeed } ." ) redcar = Coche () redcar . drive () # Esto imprimirá 'La velocidad máxima es 200'.carro rojo . _maxspeed = 10 coche rojo . drive () # Esto imprimirá 'La velocidad máxima es 10'.Los mecanismos de encapsulación permiten al programador agrupar datos y las subrutinas que operan sobre ellos en un solo lugar, y ocultar detalles irrelevantes a los usuarios de una abstracción.