"Asigna un valor de negocio a lo que son datos sueltos."

-- ✍️ Alguien que ha programado mucho

Este tema lo he titulado en positivo "Cohesión de primitivos". Suele relacionarse negativamente con el anti patrón o bad smell Primitive Obsession.

La idea central es reducir el uso de variables de tipos básicos, primitivos, de tu lenguaje. En concreto booleanos, números, cadenas y fechas.

Y dirás, claro, pero es que justo esos son los tipos de datos más comunes. Lo sé; y está bien usarlos. Pero no para crear obsesivamente variables o argumentos de funciones. Mejor emplearlos dentro de estructuras de datos, en forma de propiedades.

🧙🏼‍♀️ Guías

Para ayudarte he recogido una serie de consejos que te puede servir de guía. Se basan en la creación de estructuras de datos no inteligentes. Te recuerdo la primera máxima de Uncle Bob al respecto.

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

-- ✍️ Robert C. Martin

😶 Sin comportamiento de negocio: poca o ninguna función

Por lo tanto, si tu lenguaje te lo permite, debes utilizar el artificio más simple. Quizá un struct o un simple Object Literal { prop: value }.

💞 Cohesionan variables relacionadas

Cuando dos o más variables aparecen juntas al inicio de un módulo, en una función o van como argumentos... cabe preguntarse si tienen una relación.

🤮
let amount = 10;let currency = 'EUR';
💐
let price = {
  amount: 10,
  currency: 'EUR'}

📦 Suelen tener nombres de Entidades

Al ser almacenadores de datos es normal que se comporten como cualquier otra variable o clase. Por tanto las reglas de nombrado que le aplicamos es la del sustantivo. Pero además, en muchas ocasiones reflejan entidades del modelo de negocio.

👴 Composición mejor que herencia

Los proyectos reales manejan una enorme cantidad de información. Y en muchas ocasiones sus datos tienen un formato similar.

En el paradigma orientado a objetos es tentador recurrir a la herencia para aprovechar trabajo. Pero casi nunca es buena idea. Más temprano que tarde aparecerán casos con herencias múltiples e incompatibles.

La solución recomendada para reutilizar código es la composición de estructuras. Es decir crear estructuras muy pequeñas, que sirvan para montar jerarquías más grandes. Consulta el laboratorio para un ejemplo.

⚠️ Límites

Para terminar, intenta establecer unos límites que te ayuden a detectar problemas.

  • 👉🏼 1 ↔ 2 👈🏼 variables juntas con tipos primitivos
  • 👉🏼 2 ↔ 8 👈🏼 propiedades por estructura
  • 👉🏼 1 ↔ 4 👈🏼 niveles de jerarquía
  • 👉🏼 0 ↔ 1 👈🏼 niveles de herencia

Son rangos de confianza para examinar objetivamente el código del equipo. Pero siempre con sentido común.

"Crea muchas estructuras pequeñas, y agrúpalas en jerarquías cuando sea necesario."

-- ✍️ Alguien que ha programado mucho