viernes, 10 de junio de 2016

Novatos “Expertos”

Recientemente me encontraba trabajando con uno de estos programadores que creen que programar es “echar” líneas de código, y que piensan que conocer un lenguaje de programación los hace programadores como tal. Este individuo en cuestión, incluso parloteaba sobre Patrones de Diseño, más específicamente sobre el patrón de diseño Factory.

Cuestionaba este sujeto el uso del patrón Factory a lo largo de un  código. Él no estaba de acuerdo, y decía que uno usa el Factory es “cuando no sabe que clase va a instanciar”, que si sabemos cuál es la clase no debemos usar Factory porque es más lento que la instanciación directa del objeto y además introducimos mucha “indirección”, esa es la palabra que usó,  en el código.

Esto sólo demuestra un par de cosas.
La primera es que tenemos a alguien que cree que conoce algo.
La segunda es que lo conoce MAL.



En primer lugar el patrón Factory no se usa porque sepamos o no que clase debemos instanciar. Se usa porque garantiza que de ser necesario cambiar la clase que estamos instanciando por una nueva, otra implementación, podamos hacerlo sin tener que buscar por todo el código en dónde fue que usamos o instanciamos la clase. Su uso se justifica cuando las implementaciones pueden cambiar con cierta regularidad.


En otras palabras, si debemos modificar la clase a instanciar, existe un único punto o sitio en el que esa instanciación ocurre, y eso es en el Factory.

Sí combinamos esto con el uso adecuado de interfaces y principios SOLID, entonces nuestro código resultará más fácil de mantener, en el sentido de que no es necesario modificar lo que ya funciona con miras a introducir cambios o ampliaciones en el sistema.

Claro que es más rápido para el programador escribir algo como:


Class Document{ 
   Document(){                } 
   Document(String type){                } 
} 

// al usar la claseDocument

  doc= new Document(); 
  Document docXml= new Document(“XML”);

Usando la palabra clave new obtenemos una instancia de la clase Document. Directo. Rápido. Fácil.

No tanto…

Imaginemos que tenemos un sistema o programa realmente grande, con muchos programadores, muchos módulos, y hemos hecho uso intensivo de la clase Document; es lógico pensar que tenemos entonces muchas instancias de esa clase a lo largo del código, digamos que tenemos unas 300 instancias, en otras palabras, hemos usado new Document();, o su versión sobrecargada, unas 300 veces.

Ahora imaginemos que, por nuevos requerimientos, es necesario que sustituyamos todas las instancias creadas con el constructor sin parámetros por la nueva clase DocumentNotTyped, y las instancias creadas con el constructor con parámetros por la nueva clase DocumentTyped.

Esto implica que, de algún modo ya sea automático o manual, debemos buscar en todas los fuentes donde es que usamos la sentencia para instanciar la clase Document, y reemplazarla por la sentencia adecuada a la clase nueva correspondiente. Esto a su vez implica que hay que recompilar todos los archivos fuentes modificados, empaquetar la aplicación o sistema y distribuir la nueva versión o actualizarla donde corresponda.

Con el uso adecuado de patrones de diseño, los principios SOLID e interfaces podríamos hacer todo esto tan solo escribiendo las clases nuevas, hacer que implementen la interface adecuada y configurar el Factory para que nos devuelva la implementación (instancia) adecuada según corresponda a cada caso.
Muchos menos archivos que modificar. Mucho menos archivos fuentes que compilar. Y, lo más importante, no se modifican, tocan o cambian ninguna de las implementaciones existentes, por lo que no se introducen nuevos errores en cosas que ya funcionaban.

Como ven, el uso del patrón Factory no tiene que ver con que no sepamos cuál clase vamos a instanciar, sino que tiene que ver con desacoplar  la instanciación de las implementaciones y facilitar el mantenimiento.
Así que Novatos, por favor tengan claro los conceptos, digiéranlos bien, entiéndanlos y practíquenlos antes de querer hacer afirmaciones como “Expertos”.

En próximos artículos hablaremos sobre los patrones de diseño y los principios SOLID.

No hay comentarios:

Publicar un comentario