Encapsulamiento en Java

Imaginemos que se crea una clase, una docena de programadores tienen acceso a dicha clase y la utilizan a discreción, posteriormente dicha clase comienza a comportarse de una manera inesperada debido a que los valores que algunas variables han tomado no fueron anticipados y todo comienza a desmoronarse. Para corregir el problema se crea una versión más nueva de dicha clase y listo.

Bueno, a esto le llamamos flexibilidad y capacidad de mantenimiento, ambas son características y beneficios de la programación Orientada a Objetos (OO) pero para que una clase pueda cumplir dichas funciones los programadores debemos de hacer algo. Imaginemos que creamos una clase con variables de instancia públicas a las cuales podemos acceder sin problemas desde fuera de la misma clase...

Analizando el código anterior podemos darnos cuenta de que las variables enteras tipo y clase son públicas y pueden ser accedidas directamente a través de una instancia de la clase MiClase, esto compila sin ningún problema, digamos que es 'legal', sin embargo, ¿qué pasa si ingresamos un valor que no se supone debe de tener una variable (en este caso el -5 que le asignamos a tipo)?, simplemente no hay nada que nos detenga para hacerlo. La única manera de proteger el código es escribiendo un método que nos permita regular los valores que cada variable puede tener y escondiendo las variables para que no se pueda acceder a ellas de manera directa, esto es el principio básico de encapsulamiento.

Si se desea flexibilidad, buen mantenimiento y extensibilidad, nuestro diseño en el código debe de incluir encapsulamiento, para ello debemos de hacer lo siguiente:

• Mantener las variables de instancia protegidas (puede ser con un modificador de acceso, p.ej., private).
  
  
• Hacer métodos de acceso públicos para forzar al acceso a las variables por medio de dichos métodos en lugar de acceder directamente.
  
  
• Utilizar las convenciones de código para los nombres de los métodos, p. ej., set y get.
  
  

El ejemplo anterior modificado para un buen encapsulamiento quedaría así:

Si nos fijamos un poquito, en el método setTipo() no existen validaciones para prevenir que un valor no válido sea asignado a la variable, sin embargo, el proveer de un método de este tipo desde el diseño inicial de la aplicación nos permite posteriormente modificar el comportamiento de la misma sin afectar los métodos utilizados, tal vez en un futuro se desee que dicha variable solamente pueda tener uno entre un rango de valores y se podrán aplicar posteriormente los cambios sin que haya repercusiones negativas.