En esta entrada veremos un poco sobre lo referente a la Encapsulación en Java, que beneficios nos ofrece, para garantizar que no hay duplicidad, y añadir cohesión a las clases, al igual que describir sus beneficios.
Nos pondremos en situación:
Hemos escrito el código para una clase, y otros programadores de nuestra compañía están escribiendo programas que usan nuestra clase. Mas tarde nos damos cuenta de que nuestra clase no nos gustaba la manera en la que estaba creada, porque algunas de las variables de instancia están siendo establecidas a valores que no hemos anticipado. Su código trae errores en nuestro código (Es un caso hipotético).
Bien, es un programa en Java, por lo que podríamos ser capaces de crear una nueva versión de la clase, la cual podría reemplazar en sus programas sin cambiar nada de sus códigos.
Este escenario resalta 2 de las promesas/beneficios de la Orientación a Objetos: Flexibilidad y Mantenimiento. Pero estos beneficios no vienen solos automáticamente, tenemos que escribir nuestras clases y el código de una manera que soporte la flexibilidad y el mantenimiento. Imaginemos que hemos hecho una clase con variables de instancia public, y los otros programadores estaban asignando valores a estas variables directamente, como vemos en el siguiente código:
public class BadOO{
public int size;
public int weight;
...
}
public class ExploitBadOO{
public static void main (String[] args){
BadOO b = new BadOO();
b.size = -5; //Es legal pero está mal!
}
}
Ahora estaríamos en un problema. Nuestra única elección es ir atrás y escribir código para un método que ajuste la variable size (un método setSize(int a) por ejemplo), y entonces proteger la variable size con un modificador de acceso, como puede ser private. Lo malo, esque tan rápido hagamos esto, romperemos todo.
La habilidad de hacer cambios en nuestro código de implementación sin romper el código de otros que estén usando nuestro código es la clave del beneficio de la encapsulación. Nosotros queremos esconder los detalles de la implementación detrás de una interfaz pública de programación (API). Escondiendo los detalles de la implementación, podemos reconstruir el código del método sin forzar cambios en el código que llame a nuestro método cambiado.
Si queremos mantenimiento, flexibilidad y extensibilidad, nuestro diseño debe incluir encapsulación. ¿Como hacemos esto?:
- Mantener nuestras variables de instancia protegidas (Con un modificador de acceso, a menudo private).
- Hacer public los métodos de acceso, y forzar al código de llamada el uso de estos métodos en vez de acceder directamente a las variables de instancia.
- Para los métodos, usar la convención de nombres de JavaBeans: get y set.
Los métodos getter y setters serán los que otros programadores deben llamar para poder acceder a nustras variables de instancia. Es simple, y probablemente lo hemos estado usando siempre:
public class Box {
//Protegemos las variables de instancia
private int size;
//Proveemos getter y setter públicos
public int getSize(){
return size;
}
public void setSize(int size){
this.size = size;
}
}
¿Cómo es de útil el código anterior?¿No existen validaciones en el proceso?¿Que beneficio puede haber teniendo getter y setter que no añaden funcionalidad alguna?. El punto es, que cambiaremos de manera de pensar mas tarde, y añadiremos mas código a nuestro método sin pomer nuestra API.
Con esta explicación podemos pensar mejor sobre la Encapsulación en Java, para qué sirve proteger nuestras variables de instancia de asignaciones directas, y aunque en estos ejercicios sería fácil arreglar el problema, supongo (porque no he participado en ninguno) que una variable de instancia sin encapsular puede hacer perder mucho tiempo en el avance del proyecto.
Sin más, cualquier aporte o corrección es bienvenido.
Saludos!!!