El único principio de diseño de software importante

Si construimos todo nuestro paradigma sobre una única regla, podemos mantenerlo simple y hacer excelentes modelos.

Ser minimalista y ser axiomático implica que podamos derivar un conjunto de reglas a partir de una única definición.

Uno de los atributos de calidad más subestimados en el software es ser predecible. . pero nunca esta en el top cinco de prioridades la predictibilidad.

Vamos a hacer un ejercicio construyendo el diseño de software orientado a objetos al establecer un único principio inicial:

Cada objeto del dominio debe estar representado por un único objeto en nuestro modelo computable y viceversa.

Image for post
Image for post
La relación entre objetos del modelo y entes de la realidad es 1:1

Podemos ver la justificación de dicho modelo en este artículo:

Intentaremos luego derivar reglas y heurísticas de diseño a partir de dicho axioma, por supuesto sin contradecirlo.

El Problema

Veremos que la mayoría de las implementaciones de lenguajes utilizados en la industria ignoran esta regla y esto causa enormes problemas.

Invocando dificultades que se presentaban en la construcción de software hace 4 o 5 décadas y que ya casi no existen o están presentes en unos pocos dominios seguimos tomando decisiones como

Image for post
Image for post
Experimento de los monos y las bananas

Los modelos al rescate

Al construir modelos de cualquier tipo queremos poder simular las condiciones que se dan en la realidad observada de modo de poder seguir cada elemento de interés en nuestra simulación y estimularlo para observar los cambios de la misma manera que suceden en el mundo real.

Los meteorólogos realizan modelos matemáticos para poder predecir y anticipar el comportamiento del clima. La mayoría de las disciplinas científicas se basan en dichas simulaciones.

Con el auge del machine learning construimos modelos de caja negra para predecir comportamientos en la vida real.

La importancia de la biyección

En el dominio del software y bajo el paradigma de objetos siempre tendremos un y sólo un objeto representando un ente del mundo real.

Tratemos de demostrar por el absurdo que pasaría si no cumpliéramos con los principios de ser una.

Caso 1) Tenemos un objeto en nuestro modelo computable para representar a más de un ente del mundo real. Por ejemplo muchos lenguajes de programación modelan las medidas algebraicas utilizando únicamente la magnitud escalar.

Entonces podemos representar 10 metros y 10 pulgadas (dos entes completamente diferentes en el mundo real) por un único objeto (el número 10) y podríamos sumarlos entre sí obteniendo que en nuestro modelo el número 10 (representando 10 metros) + el número 10 (representando 10 pulgadas) es igual al número 20 (representando vaya a saber qué cosa).

Image for post
Image for post
La relación entre el número 10 y las mediciones no es biyectiva

Esto genera problemas no siempre capturados a tiempo. Al tratarse de una falla semántica, el error suele ocurrir mucho tiempo después de la falla como en el célebre caso del

Image for post
Image for post
La sonda explotó al mezclar diferentes unidades de medidas

Caso 2) Nuestro modelo computable representa con dos objetos un mismo ente de la realidad.

Supongamos que tenemos en nuestro recorte de la realidad un atleta John Smith que compite en una disciplina pero que también es juez en otra disciplina atlética.

Como representa a una única persona en la realidad debería ser un único objeto en nuestro modelo computable. Si tenemos dos objetos diferentes (un competidor y un juez) que representen a John Smith vamos a tener tarde o temprano inconsistencias al querer asignarle alguna responsabilidad a uno de los dos y no verla reflejada en el otro.

La solución a este tipo de problemas es dejar de ver a los entes como estructuras de datos con atributos, pensarlos como objetos y entender que son el mismo objeto cumpliendo diferentes roles según el contexto en el que estén interactuando.

Casos comunes en la industria que violan la biyección

En la mayoría de los lenguajes de programación de objetos modernos se puede construir una fecha construyéndola a partir de su día, mes y año.

Todos aprendimos que se puede crear un 31 de noviembre y que la mayoría de estos lenguajes gentilmente nos van a retornar un objeto válido (probablemente un 1 de diciembre).

Esto que parece un beneficio no dejar de ser un caso de ocultamiento de errores generando acoplamiento hacia la decisión de diseño que haya tomado el lenguaje de programación.

El error escondido en la carga de datos fatalmente aparecerá al correr un lote nocturno de procesamiento de dichas fechas muy lejos de la causa raíz violando el principio de .

La Biyección

En esta serie de artículos hablaremos de manera indistinta mencionando a la biyección o a MAPPER como nuestra única guía de diseño axiomática.

Recordemos que MAPPER representa

Conclusiones

En este artículo definimos axiomáticamente la única regla de diseño que respetaremos a rajatabla justificando los problemas que acarrea no respetarla y sentando las bases para futuras definiciones derivadas de ella.

Parte del objetivo de esta serie de artículos es generar debates y espacios de discusión sobre la problemática del diseño de software.

Esperamos ansiosamente los observaciones y comentarios sobre este artículo.

Agradecimientos

Parte de las ideas de este artículo fueron desarrolladas junto con Hernan Wilkinson y todos los demás miembros de la cátedra de Ingeniería de Software de la

Este articulo esta publicado al mismo tiempo en Ingles .

Written by

I’m senior software engineer specialized in declarative designs. S.O.L.I.D. and agile methodologies fan.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store