Porque las estructuras de datos deben estar ocultas en un sistema software (1/2)

Hace ya casi cuarenta años, en el 72, de la aparición del primer artículo que trató aquello de la “ocultación de la información”. Artículo que firmaba Parnas, persona muy importante en la historia de la ingeniería del software. La ocultación de la información o encapsulación, sin entrar en tecnicismos (le dejo eso al artículo), trata la idea de que los módulos software (bien sean clases, paquetes, sistemas, etc.) deben ocultar su información interna al resto, ocultar sus estructuras de datos, incluso su diseño, para evitar así que a otros módulos se les ocurra depender de estas estructuras de datos internas, accediendo a ellas directamente para obtener información. Para evitarlo los módulos deben proporcionar una interfaz y que sea sólo a través de ella, a través de «métodos», la única forma de obtener información de un módulo software. De ahí, por ejemplo, la buena práctica de que una clase debe declarar sus atributos o estructuras de datos como privadas, para que ningún objeto pueda acceder directamente a las mismas y sólo pueda obtener información por medio de un servicio.
Como todo en esta vida, esto también tiene una razón, o varias. Si un módulo pudiera acceder, leer atributos o estructuras de datos de otro, entonces principalmente ocurrirían dos cosas…
1 – Si un día queremos cambiar las estructuras de datos nos será muy complicado, porque tendríamos que modificar a todo aquel módulo al que se le permitió acceder a ellas. Pongamos un ejemplo, imaginemos que un módulo o un objeto tiene un dato “edad”, que está almacenado en una estructura simple (un atributo tipo entero), pero tiempo después nos da por querer almacenar las 10 últimas edades y para ello sustituir el entero por un array de enteros… tendríamos entonces que buscar a todos aquellos módulos que accedían directamente al dato simple edad y modificarlos para que ahora lean un array.
Enlace a la segunda parte de este post

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *