jueves, 5 de noviembre de 2015

La inyección de propiedades es el mal encarnado.

En StackOverflow no paro de encontrarme a gente preguntando como se realiza la inyección de dependencias en las propiedades, en vez de en el constructor, de una clase con tal o cual contenedor.

Las putillas kármicas que quieren puntos de reputación sin importarles lo demás un carajo se dedican a poner las 4 líneas de código de turno y se llevan sus 15 puntitos calentitos.

Yo, a costa de no recibir puntuación ninguna, prefiero responderles con ética y plantarles un "WRONG WAY, TURN BACK!!" bien gordo al principio de la respuesta y luego una extensa explicación que nadie se preocupa en leer.



 Cuando alguien busca inyección de dependencias a través de la propiedades públicas o los campos de una clase en vez de en el constructor suele ser por que les está quedando un constructor muy largo con un buen montón de dependencias como parámetros de entrada; esto les parece un problema de legibilidad del código y quieren refactorizarlo para que quede más limpio y bonito.

Pues a esta gente les digo que su problema raíz no es de legibilidad del código; su problema es el diseño de las clases y/o las capas de software. Si una clase; una entidad que encapsula datos y comportamiento con un propósito y unas fronteras fuertemente definidas; tiene muchas dependencias entonces es que se está realizando un diseño incorrecto. Obviamente, una de las consecuencias colaterales de un mal diseño es un código ilegible por la falta de contexto (o por un contexto mal definido o demasiado extenso). De hecho, más del 80% del código ilegible que me he encontrado a lo largo de los años es consecuencia de un mal diseño y no de la dejadez del desarrollador con respecto a la cuestión de la legibilidad.

Así que, mantener la inyección de dependencias en el constructor, no sólo ayuda a no ocultar las dependencias haciéndolas implícitas en vez de explícitas y con contexto (cosa buena, creedme) si no que, encontrarse con un constructor largo y lioso se convierte en una señal de alarma de mal diseño para el desarrollador; y tener siempre presente un buen conjunto de señales de alarma mientras se construye la implementación de un sistema es una de las cosas que yo más valoro en un desarrollador de software y aporta muchísimo al feedback interno del diseño y desarrollo de un sistema.

Moraleja: Nunca tendré una reputación alta en S.O. pero dudo que eso sirva para algo en una Españistán tercermundista donde lo único que se desea es servilismo y no competencia.

4 comentarios:

  1. Hay un único sitio que conozco que no tienes otro remedio a no ser que que hagas algo rebuscado que es, desgraciadamente, en WebForms. Pobrete él.

    ResponderEliminar
    Respuestas
    1. Pues si. Tienes toda la razon. De hecho hace poco lei un comentario que decia: "¿No se invento la inyeccion de propiedades debido a la existencia de webforms?" ;)

      Eliminar
    2. Supongo que es como todo. Al final todo depende de lo preparado que esté el desarrollador. En mi caso, para los ultimos proyectos en WebForms que hice me acostumbre que, desde la página, sólo hubiera un único punto con inyección de dependencias que cargara el presentador de la página y, a partir de ahí, magia. Y esto lo hacia mediante clases base abstractas para ensuciar lo más mínimo. Lo veía feo, pero si Microsoft en vez de llorar ayudara un poco.... vamos no creo que cueste mucho agregarle un punto de inyección de sus páginas. Y si no lo ha hecho nadie es porque toda la chicha de creación de las páginas esta ahi interno en sus dll sin que se pueda extender, modificar o substituir fácilmente.

      Eliminar
    3. Si, yo hice algo parecido. En el PreRequestHandlerExecute metia un BuildUp de Unity si el IHttpHandler era clase Page.

      Eliminar