"Los malos programadores se preocupan por el código. Los buenos se preocupan por las estructuras de datos y sus relaciones."

-- ✍️ Linus Torvalds.

Esta frase lapidaria no me atrevería a ponerla si no viniese firmada por uno de los grandes de la programación. Quizás yo la hubiera suavizado diciendo que las estructuras de datos nos ayudan a mejorar nuestros programas.

Pero, ¿a qué se refiere al pedirnos que nos preocupemos por las estructuras de datos? ¿No es algo que ya hacemos todos? Vamos a puntualizar. Lo que hacemos todos es usar estructuras de datos para mostrar, almacena y transmitir información relevante para el problema de negocio tratado.

Esto es imprescindible y se ha estandarizado en leyes, buenas prácticas, patrones y anti-patrones según cada cual; pues hay para elegir: documentos, normalización relacional, DTOs, ActiveRecord, POJOs... Efectivamente, creo que todos nos preocupamos por este tipo de estructuras.

En código limpio nos preocupamos además por dos usos de los datos con impacto en la legibilidad y mantenimiento del código.

Por un lado está la cohesión de tipos primitivos en estructuras que aporten orden y significado. El infame code smell "Primitive obsession".

Por otra parte tenemos el uso de estructuras para simplificar condiciones lógicas que de otro modo están hard coded dificultando el mantenimiento.

En cualquier caso se resuelve creando unas estructuras muy simples. Según el lenguaje (idioma) en el que programes puede que tengan nombre propio. Por ejemplo struct en C# o un object literal de JavaScript. A veces requerirán una clase para darle cuerpo; pero nunca expondrán métodos con lógica de negocio. Esos son otros objetos que aún no tocan en este tutorial.

Nos lo resume Uncle Bob en dos máximas; aquí va la primera:

"La estructura de datos expone sus propiedades y no tiene funciones significativas"

-- ✍️ Robert C. Martin