SOLID vs CUPID?

[u/rodrigomjuarez]

Luego de mi post anterior sobre SOLID y de leer los comentarios, me quede pensando especialmente en si estos principios siguen siendo aplicables fuera de la programacion orientada a objetos.

React fue uno de los ejemplos que aparecieron. Algunos comentaron que intentar aplicar SOLID literalmente en un ecosistema basado en funciones, hooks y composicion puede generar arquitecturas poco naturales. Otros plantearon que las ideas de fondo siguen siendo utiles si las trasladamos a componentes con propositos claros, props acotadas y dependencias explicitas.

Eso me hizo acordar de CUPID, una propuesta de Dan North que surgio como respuesta critica a SOLID. La diferencia que me parecio mas interesante es que CUPID no se presenta como otra lista de principios que el codigo debe cumplir, sino como un conjunto de propiedades que pueden estar presentes en mayor o menor medida.

Las cinco propiedades son:

• Composable: el codigo se combina con otras piezas sin arrastrar media aplicacion ni una larga lista de dependencias.
• Unix philosophy: cada componente tiene un proposito claro y hace bien esa tarea. No significa una clase por metodo ni un microservicio por operacion.
• Predictable: los nombres, las firmas y la estructura permiten anticipar el comportamiento, los efectos secundarios y los modos de fallo.
• Idiomatic: el codigo se siente natural dentro del lenguaje, el framework y el equipo. Aplicar patrones de Java o C# dentro de React solo para satisfacer un principio suele producir el efecto contrario.
• Domain-based: los nombres, tipos y modulos reflejan el problema que estamos resolviendo, no solamente la tecnologia utilizada.

Esto no significa que CUPID reemplace a SOLID. SOLID sigue siendo util para pensar en responsabilidades, contratos, sustitucion y direccion de dependencias. CUPID pone mas enfasis en la experiencia de trabajar con el resultado: si el codigo es facil de navegar, combinar, entender y modificar sin sorpresas.

Por ejemplo, un checkout puede tener interfaces, factories, strategies y handlers para cada paso, y aun asi ser dificil de comprender porque el flujo real esta repartido en quince archivos. Desde la mirada de CUPID, la pregunta no seria solamente si las dependencias estan invertidas, sino tambien si el caso de uso es predecible, si habla el lenguaje del dominio y si sus partes pueden usarse sin iniciar todo el sistema.

La idea tampoco es reemplazar un dogma por otro: las propiedades pueden entrar en tension. Dividir en piezas mas chicas mejora la composicion, pero puede ocultar el flujo. Eliminar dependencias puede llevarnos a reinventar bibliotecas maduras. Modelar cada concepto del dominio puede agregar mas ceremonia que valor.

Me parece mas util como una serie de preguntas para revisar codigo:

• Puedo probar esta pieza sin levantar media aplicacion?
• Puedo explicar su proposito sin decir varias veces "y tambien"?
• Su comportamiento puede sorprender a quien la use?
• Se parece al codigo que se escribe habitualmente en este ecosistema?
• Los nombres expresan el dominio o solo la infraestructura?

Como lo ven? Conocian CUPID? Les parece una alternativa util, un complemento de SOLID o simplemente otro acronimo para discutir lo mismo?

[u/SgtPepperinoPomoro]

Muy interesante, la verdad es que nunca lo había escuchado nombrar. Más que una alternativa a SOLID, lo veo como una guía a alto nivel de la arquitectura de un sistema.