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

Segunda parte del post de ayer, con el segundo problema… y una anécdota final.
2 – El módulo externo que acede a la estructura de datos de otro podría leer datos no actualizados. Por ejemplo, un módulo podría guardar el dato edad y no tenerlo actualizado. Si se accede directamente a una estructura de datos nadie se responsabiliza de que lo que lee esté actualizado. Pero si accedemos a través de una interfaz, de un servicio, un método, un “getEdad”, este puede asegurarse de actualizar el dato en el momento en que se pide. Además de que una cosa son las estructuras de datos y otra la información que un módulo nos puede proporcionar, que es sus estructuras de datos o atributos + los cálculos que puede hacer con ellos.
Contaba esto el otro día en una de mis clases de la Universidad Rey Juan Carlos y como siempre que cuento esto alguien preguntó “pero entonces ¿cómo vamos a evitar que un módulo qué pide información sepa qué esa información es de de tipo entero, booleano o lo que sea?”. Esta regla no habla de no conocer tipos de datos primitivos, eso no es el gran problema, la regla se centra en no conocer “estructuras de datos”.
Y también siempre que sale este tema me viene el recuerdo de tantos pobres proyectos que por incumplir esta práctica se fueron poco a poco convirtiendo de “dinosaurios” cada vez más difíciles de evolucionar y modificar. Recuerdo especialmente cierta aplicación, de tamaño importante, cuyos desarrolladores incumplían sistemáticamente esta práctica. Y los módulos estaban totalmente acoplados a estructuras de datos a las que accedían directamente. Destacaban especialmente los accesos a la base de datos, a la que todos los módulos accedían sin  pasar por una interfaz o fachada de servicios. Todos los módulos tenían un trocito de SQL dentro. SQL no estándar, dependiente de un sistema gestor de base de datos (SGBD) concreto. Y llegó el día en que se planteó la cuestión de cambiar el SGBD, porque el fabricante ya no daba más soporte, al ser una versión antigua. Pero, claro, para cambiarlo había que recorrer muchos cientos de trozos de código revisando y actualizando su SQL. Y el coste y riesgo de dicha migración era tan grande que se decidió seguir utilizando el SGBD antiguo y pagar “eternamente” un soporte especial al fabricante.

• Acerca de
• Últimas entradas

Javier Garzás

Javier Garzás es Doctor (Ph.D) en Informática, con un
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.

Últimas entradas de Javier Garzás (ver todo)

• Truco (con IA o sin ella) para espiar (legalmente) a tu competencia - 6 marzo, 2025
• Lo que NO te aconsejo hacer si quieres que SI se valore tu conocimiento - 27 febrero, 2025
• Como una PIZZA te puede dar una clase magistral de IA - 20 febrero, 2025