Cuando utilizar el Patrón de Diseño Factory en Laravel

Cuando utilizar el Patrón de Diseño Factory en Laravel

Hace poco me preguntaron para que servía exactamente el Patrón Factory y si era algo que se podía usar en Laravel

La respuesta a la primera pregunta es que un Factory:

Nos ayuda a crear instancias de otras clases, con la finalidad de ocultar la complejidad que se requiere para crear esas clases.

y claro que puedes usarlo en Laravel!

Es mas, Laravel utiliza este patrón en varias partes de su código.

Los patrones de diseños son ideas, y como tales lo mas importante es entender para que sirven y luego ver como podemos usar esa idea en el código.

Bien déjame presentarte al Patrón Factory en su forma mas básica.

Simple Factory Classes

En código esto puede representarse de la siguiente forma.

Como puedes apreciar es solo una clase con un método que crea una instancia de otra!

y si lo pensamos un poco mas, también puede crear mas de una instancia.

nada fuera de lo común, la forma de usar esta clase es como sigue.

Una clase que se conoce como “Cliente” que en la mayoría de los casos puede ser nuestro Controller va a usar el SimpleFactory, Para crear otra clase (OneClass) mediante su método make

Todo esto se puede resumir en código como sigue.

Sí lo piensas puedes meter lo que necesites en ese método make y obtener la instancia que tu quieras!

¿Cómo puedo utilizar esto en algo real?

Es lo que veremos en este articulo

Pero vamos por pasos, ya sabemos que son los Patrones Factory, ahora debemos saber cuando no y cuando sí utilizar este patrón.

¿Cuando no utilizar el Patrón Factory?

Este patrón como en todas las cosas, tiene un caso en el que no nos beneficia en nada.

y es cuando podemos instanciar una clase con algo tan simple como

Es obvio que no podemos simplificar esto de alguna forma adicional.

Otro caso;  es en el que podemos instanciar de alguna forma la clase sin tener que utilizar el Patron Factory como en este ejemplo:

vamos a suponer que la primera vez que se crea un usuario debe de tener un estado de “pendiente”, por lo cual tenemos ‘state’ = User::PENDING. 

Este caso podemos resolverlo estableciendo un valor por defecto, por ejemplo podemos utilizar el arreglo attributes para establecer el valor por defecto en el modelo:

Otra opción es establecer el valor en la migración o usar eventos de Eloquent.

en cualquiera de esos casos el cambio hará que tengamos una llamada mas simple:

Por lo cual usar un factory no nos ayudaría a mejorar nuestro código.

Así que en este punto es posible que te preguntes…

¿Cuando debemos de utilizar el Patrón Factory?

Existen dos casos en los cuales podemos sacar provecho de este patrón y son los siguientes.

Caso 1: El objeto que necesitamos crear, puede cambiar y afectar su utilización

Este caso cubre las situaciones en las que la clase puede cambiar de nombre o puede cambiar la firma de su constructor en cuanto al numero de parámetros o tipo de datos que la clase necesita para instanciarse.

Es evidente que un cambio en el nombre de la clase o de la firma del constructor, afectara el uso de la clase en donde sea que la utilices.

Aquí el Factory te protege contra cambios que se originan de estas situaciones.

Un ejemplo practico es en el uso de name constructors, como en el caso de la clase Carbón.

Como puedes observar, en este caso cambia la firma y el tipo de parámetro que se requiere para crear el objeto Carbon,

Por esta razón requerimos examinar el contenido del $request para decidir que name constructor se va usar para obtener una instancia de Carbon.

Si copiaras esto e intentaras usarlo en otras partes de tu código y luego tuvieras que cambiar algo nuevamente, tendrías que hacerlo en todos los lugares donde usaste este parte del código.

Para evitarte la molestia de tener que hacer todos esos cambios, puedes usar el Simple Factory para que contenga toda esa lógica y si tienes que cambiar algo.

Solo lo haríamos en el Simple Factory y creo que eso sería genial!

Así que movamos todos esas condiciones a un mejor lugar.

Este cambio nos deja con un código como el siguiente.

¿Qué tal?, se entiende mucho, mucho mejor y simplificamos las cosas.

 Caso 2: Cuando no sabemos el tipo de objeto que vamos a recibir (Tiempo de ejecución)

EL tipo de situaciones que derivan de este caso son aquellas en las que se requiere

de lógica de decisión para determinar el tipo de objeto o la forma en la que se va a construir.

Este tipo de decisiones obviamente se determina durante la ejecución y es por eso que no podemos saber de forma anticipada el tipo de objeto que se va a utilizar

¿Cómo es esto?

Un ejemplo practico es por ejemplo cuando podemos decidir el formato para generar y descargar un reporte como en el siguiente ejemplo.

Como puedes observar el resultado del tipo de reporte depende de la elección que se envía en el request.

Este tipo de lógica puede colocarse en el Simple Factory, para simplificar el controlador y reducir el riesgo de cambio.

Así que hagamos una clase para ese propósito.

Ahora veamos como queda nuestro controlador

¿Sencillo no lo crees? con un cambio mínimo, hemos logrado que el código se entienda mucho mejor,

ademas si algo cambia en el Switch no debemos de preocuparnos, porque el controlador puede seguir trabajando si cambios adicionales.

Resumen

En esta ocasión te dejo un vídeo para esta parte 😀

 

Y para finalizar recuerda, los mas importante es la idea así que aplica este concepto!!

No tengas miedo, que te valga un pepino como queda, recuerda, nadie va a calificar tu código y no esperes tener una implementación “Pro”.

Mejor soluciona tu caso, ve como te funciona y luego mejora el código que resulte de hacer uso del Patrón Factory.

Y después, estudia otras formas de este patrón.

Me despido y recuerda compartir este articulo y claro deja tus comentarios!

Comparte este artículo

Entra en la discusión y deja tu comentario

Veces