Hola gente, como están? Les comento que actualmente me encuentro trabajando en el desarrollo de un sistema ecommerce con Laravel. Por el momento, estamos en la etapa de diseño y análisis.
Detectamos que la parte de cupones de descuento que tendrá el sistema, será algo bastante complejo. Mas que nada por la cantidad de distintos tipos de cupones y reglas que tendrán cada uno de ellos para ser aplicados al carrito.
Por eso decidimos tratar la «aplicación de los tipos de cupones» como un subsistema del sistema de cupones. Así que, esta situación me da el pie para escribir sobre Facades en Laravel y mencionar un tip muy interesante.
¿Qué son las Facades de Laravel?
Las Facades (o Fachadas) son un patrón de diseño de la Programación Orientada a Objetos que nos permite ocultar un subsistema detrás de un objeto.
Las Facades no son algo propio de Laravel, pero si que las utiliza bastante. Puedes ver todas las fachadas de Laravel en el archivo config/app.php en la sección de «aliases».
¿Cómo utilizar una Facade en Laravel?
Como les comentaba, en el proyecto de ecommerce que estoy trabajando todavía estamos en la etapa de diseño y no comenzamos a tirar código pero voy a escribir como supuestamente quedaría.
Supongamos que tenemos un modelo llamado Cupon y decidimos que aquí estará la función para aplicar los cupones. El código sería algo así:
Imagínense la cantidad de código que va a tener el método aplicar() para cada uno de los distintos tipos de cupones y las reglas que deben cumplir para ser aplicados. Nos quedaría enorme! Y cada vez que se cree un nuevo tipo de cupón crecerá más y se complicaría aun más.
Vamos a ver como se mejoraría con Facades.
Implementando Facades
Para mejorar el ejemplo anterior utilizaremos el patrón de fachadas de la siguiente forma:
Con este diseño, la complejidad y la implementación de como se aplicarán los cupones queda oculta en un «subsistema» al que se accede por la fachada TiposDeCupon.
Lo llamo «subsistema» porque podría contener distintos objetos por cada tipo de cupón y, a su vez, objetos para validar que se pueda aplicar dicho cupón, etc, etc. No lo se, eso ya será cuestión del programador que le toque desarrollar la lógica de cada cupón.
Lo importante es que estamos generando un único punto de acceso a la forma que se aplican los cupones gracias a la Fachada. De esta forma, se consigue una separación de responsabilidades delegando a un subsistema todo el manejo de aplicación de cada cupón. A su vez, este subsistema puede seguir creciendo y a la función aplicar() del Modelo no le importaría.
Laravel Tip: Facades en tiempo real
En este Laravel Tip vamos a ver una mejor forma de llamar a las fachadas y es con Facades en tiempo real. Laravel llama Facades en tiempo real a la forma de utilizar las fachadas sin la necesidad de instanciarlas. Veamos como se hace.
Como podemos ver, lo único que hicimos para transformar nuestra facade en una facade de tiempo real fue agregar Facades\ al use. Pero ojo! esto no quiere decir que creamos una carpeta «Facades» o algo por el estilo. No, solamente agregue «Facades\» al use de App\TiposDeCupon y Laravel se encarga de todo.
Gracias a las Facades en tiempo real de Laravel, podemos llamar a cualquier método de la fachada como si fueran métodos estáticos.
Las Facades en tiempo real están disponibles desde Laravel 5.4.
Hasta acá este artículo, espero que les haya gustado y tengan en cuenta las Facades para abstraer funciones complejas de sus sistemas. Nos vemos en la próxima 😉🤙.
Estaría bueno si pudieras explicar mas con el ejmplo como quedaría la logica y los returns de TiposDeCupon
Concuerdo con el comentario anterior, siento que el articulo se queda a mitad de la explicacion …
Bueno, jejeje. Venia a comentar lo mismo que los comentarios anteriores, siento que le falto mas explicación. No entendí dos cosas, el segundo parámetro de la función que vendría siendo $this. Y que retorna la función aplicar, si es una collecion, un array, un valor.
Yo lo que entendí es que TiposDeCupon tendra muchas funciones y logica y para no poner todo ese codigo en el modelo, lo pone en una fachada.
Esta bueno porque un programador se podria encargar de hacer toda la logica de TIposdeCupon y otro programador encargarse del modelo cupon
Es que justamente el código de la fachada no importa.
Por ejemplo, alguien se pregunta que devuelve la función get() cuando hacemos Route::get() o como utiliza sus parametro, o que devuelve? No, y eso es porque Laravel envuelve el subsistema de rutas en la fachada «Route» y a nosotros, como programadores de Laravel, solo nos interesa que haga lo que tenga que hacer y no el «como» lo hace.
Este es el mismo caso pero aplicado a nuestro sistema. Llamamos a aplicar() de TiposDeCupos y listo, sabemos que va a aplicar el tipo de cupón (primer parámetro) al cupón que le pasamos como segundo parámetro ($this).
En ese caso No cubre el mismo objetivo simplemente incluir un archivo que tenga la función “aplicar”? Sabemos lo que va a hacer pero no el como, y cumple el mismo objetivo, que caso tiene usar el patrón Facade, siento que lo único que se hace es trasladar ese switch enorme a otro archivo, pregunto porque realmente quisiera entenderlo.
Te refieres a hacer un
include('funcion-aplicar.php')?El problema es que no sera una simple función
aplicar(), tendrá bastante lógica dependiendo el tipo de cupón que se va a procesar.Voy a ver si puede hacer un artículo explicando que habría en
aplicar(). Voy adelantando que elswitchlo voy a reemplazar por algo mejor 😁.Me encanto este tip! muy bueno! lo implemente y me esta ayudando a organizar el codigo! gracias!
Muchas gracias Sebastian, me alegra que te allá servido el tip. Saludos.
Igual valdría un poco la pena que pudieras explicar más sobre la estructura, estuve leyendo algunos articulos y en unos crean los folder App\Facades y App\Tools por ejemplo … dónde desde facades solo hacen return de lo que viene de tools, etc…
Esto y nada es lo mismo pichita