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”.
Comentarios
Publicar un comentario