Pereza I: Meta-programación

La meta-programación es mágica. Esa es la razón principal por la que no deberíamos usarla. Hay muchas terribles consecuencias en el horizonte.

Con la meta-programación pasa lo mismo que con los patrones de diseño:

  1. No los entendemos.
  2. Los estudiamos a fondo.
  3. Los dominamos.
  4. Leemos la biblia que nos dice que los patrones están en todos lados.
  5. Abusamos de ellos pensando que son una bala de plata.
  6. Aprendemos a evitarlos.
Image for post
Image for post
Photo por Chase Clark en Unsplash

La magia está al alcance de la mano

Cuándo usamos meta-programación lo hacemos predicando sobre el Metalenguaje y el Meta Modelo. Esto implica subir un nivel de abstracción al hablar por sobre los objetos del dominio del problema.

Image for post
Image for post
El meta-modelo no está presente en la realidad

Abierto pero no tanto

Uno de los principios de diseño más importante es el llamado abierto/cerrado perteneciente a la definición de diseño sólido. La regla de oro indica que un modelo debe ser abierto para la extensión y cerrado para la modificación.

Image for post
Image for post
Jerarquía polimórfica de parsers
  1. Utiliza a las subclases con meta-programación, por lo tanto, al no existir referencias directas, no serán evidentes sus usos y referencias.
  2. Al no existir referencias y usos no se podrán realizar refactorizaciones directas, conocer todos sus usos ni evitar borrados accidentales.
  1. Generamos una dependencia a un proveedor de parsing utilizando Inyección de Dependencias (la D de Solid).
  2. En distintos ambientes (producción, testing, configuraciones) utilizamos distintos proveedores de Parsing y no nos acoplamos a que pertenezcan a una misma jerarquía.
  3. Utilizamos acoplamiento declarativo. Le pedimos a dichos proveedores que realicen la interfaz ParseHandling.

Sin referencias no hay evolución del código

Image for post
Image for post
Foto por John Doyle en Unsplash

La excepción define a la regla

Ya hemos demostrado que utilizar meta programación para referirse a nuestras entidades del mundo real violando el principio de la biyección es una mala práctica. Entonces ¿Para qué deberíamos usarla ?

  1. La serialización de entidades
  2. La impresión o ‘display’ en interfaces de usuario
  3. El testing o las aserciones

No es mi responsabilidad

Imaginemos como modelar un ente de la vida real ‘Empleado’:

Image for post
Image for post
Demasiadas responsabilidades accidentales
Image for post
Image for post
Únicamente responsabilidades esenciales

La excepción a la excepción

La mayoría de los los frameworks de testing usan técnicas de metaprogramación para recolectar los elementos a testear o casos de test

  1. Utilizar meta programación para ‘invocar’ un método privado con algún mecanismo de reflexión que evite los controles.
Image for post
Image for post
Foto por NeONBRAND en Unsplash

Más pereza

Lamentablemente, la meta programación no es el único mal generado por la pereza.

Conclusiones

La meta-programación es algo que deberíamos evitar a toda costa, utilizando en su lugar abstracciones que existen en la realidad y que sólo debemos ir a buscar pacientemente.

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