La ENCAPSULACIÓN es un principio fundamental que se refiere a la ocultar los detalles internos de un objeto, y exponerlos únicamente mediante accesos controlados a sus datos y métodos.
La encapsulación es un objeto diciendo: “No me toques mis cosas”
Los OBJETOS tienen variables internas que contienen sus datos y estado. Estas variables no están disponibles para todo el mundo, de igual forma que a ti no te gusta que te manoseen un riñón.
Si otro elementos quiere interactuar con un objeto, debe hacerlo a través de sus métodos públicos. De esta forma, el objeto puede hacer las acciones necesarias para mantener su coherencia interna.
Los lenguajes orientados a objetos restringen que los datos internos sean accedidos desde fuera del propio objeto (puede parecer algo evidente o lógico, pero es que otros lenguajes no lo hacían… y otros aún lo lo hacen 🙂).
Cómo usar la encapsulación
La ENCAPSULACIÓN se logra mediante la introducción de atributos de visibilidad a los métodos y variables de una clase.
Unido a esto, el lenguaje de programación, compilador, e intérprete, deben soportarlo y respetarlo (porque si no lo respetaran pues… lógicamente no tendrías encapsulación 🤷♂️)
Los atributos de visibilidad definen lo que es interno y lo que es público, dentro de un OBJETO. En general, mínimo debería haber dos tipos de visibilidad.
- Privado, solo accesible por el propio Objeto
- Publico, accesible por otros elementos
class Persona
{
public nombre = "Luis" // atributo publico
private edad = 12 // atributo privado
}
persona.nombre = "otro nombre" ✔️ // es publico, puedes leerlo y escribirlo
persona.edad = 14 ❌ // es privado, NO puedes leerlo ni escribirlo
Aunque otros lenguajes pueden añadir más formas de visibilidad, como protected
o internal
, por ejemplo. O diferenciar en visibilidad para escribir, y visibilidad para leer.
Pero mínimo deben tener privado
y publico
, para hablar de encapsulación.
Ejemplo de un Encapsulación
Vamos a ver cómo sería la sintaxis para definir una clase Coche
en diferentes lenguajes de programación.
En C#, se utiliza la palabra clave public
para declarar un atributo como público y private
para declararlo como privado. Estos atributos se anteponen a cada propiedad o método.
public class Persona
{
public string nombre = "Luis"; // atributo publico
private int edad = 12; // atributo privado
}
En C++, la declaración de miembros como públicos o privados se realiza mediante los modificadores de acceso public
y private
, que definen “secciones” dentro de una clase.
class Persona {
public:
string nombre = "Luis"; // atributo publico
private:
int edad = 12; // atributo privado
};
En JavaScript, no hay una distinción explícita entre atributos públicos y privados. Sin embargo, mediante el uso de la convención de nombres (usar #
delante del nombre de la variable), se puede indicar que un atributo es privado.
class Persona {
nombre = 'Luis'; // atributo publico
#edad = 12; // atributo privado
}
Python no tiene modificadores de acceso, pero se utiliza una convención para indicar que un atributo es privado (prefijo con \_\_
doble guion bajo).
class Persona:
def __init__(self):
self.name = 'Luis' # atributo publico
self.__edad = 12 # atributo privado
¿De donde viene la encapsulación?
El papel que cumple la ENCAPSULACIÓN es muy razonable. Recordemos que, antes de la Programación Orientada a Objetos, ya existía la tendencia de agrupar variables dentro de agrupaciones en forma de estructuras.
Sin embargo, no había una limitación a que cualquier otra parte del programa viniera y te cambiara un dato. Lo cuál, a día de hoy, para la mayoría es una locura.
Además, en esa época ya estaban haciendo “pseudo-objetos”, metiendo dentro de estas agrupaciones referencias a funciones. Referencias a funciones que también podían cambiarte desde cualquier parte del programa, sin aviso ni restricción.
Así que en esta especie de “proto-objetos” cualquier podía venir y cambiarte el estado interno, o incluso el comportamiento. E imaginaréis, que eso era un “sin Dios”. Por eso surge la necesidad de la ENCAPSULACIÓN.
Ya que se estaba creando el concepto de OBJETO como unidad elemental de trabajo, era lógico que se necesitaba “blindarlas” para que cada una estuviera aislada, y su acceso protegido.