{"id":251,"date":"2023-05-21T17:30:13","date_gmt":"2023-05-21T22:30:13","guid":{"rendered":"https:\/\/lafilosofiadelsoftware.com\/?p=251"},"modified":"2023-08-23T07:30:50","modified_gmt":"2023-08-23T12:30:50","slug":"facade-delegate-en-nuestras-arquitecturas-de-software","status":"publish","type":"post","link":"https:\/\/lafilosofiadelsoftware.com\/index.php\/2023\/05\/21\/facade-delegate-en-nuestras-arquitecturas-de-software\/","title":{"rendered":"Facade & Delegate en nuestras arquitecturas de software"},"content":{"rendered":"\n

Comencemos por el patr\u00f3n Facade. Imagina que tienes un problema el cual para solucionarlo requiere de diferentes conocimientos en distintos temas. Veamos el siguiente ejemplo: Tienes dificultades con la instalaci\u00f3n el\u00e9ctrica de tu hogar y hay interruptores que no funcionan correctamente junto con luces que parpadean, es tu responsabilidad <\/strong>darle soluci\u00f3n a esas dificultades, pero requieres conocimientos especializados en electricidad, como identificar circuitos, resolver problemas de cableado y reemplazar componentes defectuosos. Ante esta situaci\u00f3n, tenemos dos maneras de solucionarlo: en la primera, te conviertes en un especialista y aprendes todo lo que necesitas para solucionar la necesidad actual, y en la segunda, contratas a un electricista el cual ya tiene los conocimientos y herramientas para hacer las debidas reparaciones.
En este segundo escenario, el electricista ser\u00eda nuestro facade. Por lo tanto, ahora tu labor es \u00fanicamente comunicarle al experto qu\u00e9 dificultades est\u00e1s presentando y \u00e9l te brindar\u00e1 a trav\u00e9s de un simple llamado la soluci\u00f3n para reparar tu hogar.<\/p>\n\n\n\n

El patr\u00f3n de facade aplicado en este caso se convierte en el electricista el cual abstrae la complejidad de la soluci\u00f3n del problema y proporciona una interfaz simple para ser invocado. Podemos ver a facade como un concepto en el que se reubica la complejidad de la soluci\u00f3n de un problema, brindando una abstracci\u00f3n<\/em><\/strong> simplificada para su uso.<\/p>\n\n\n\n

Facade es, entonces, un patr\u00f3n de dise\u00f1o que busca abstraer la soluci\u00f3n de un problema, ofreciendo una interfaz simplificada permitiendo a su vez la reutilizaci\u00f3n<\/em>. Muchos ingenieros piensan e incluso afirman que facade es un patr\u00f3n que reduce el acoplamiento, cuando lo correcto que se deber\u00eda decir es que acomoda el acoplamiento, debido a que el acoplamiento para la soluci\u00f3n del problema sigue existiendo, pero ahora se encuentra en la facade.<\/p>\n\n\n\n

Veamos el siguiente ejemplo:<\/p>\n\n\n

\n
\"\"
Antes y despu\u00e9s de usar facade<\/figcaption><\/figure><\/div>\n\n\n

Observando la imagen anterior, podemos apreciar en la imagen de la izquierda c\u00f3mo cada una de las clases de ventas presenta un alto acoplamiento al tener que depender de diferentes clases y sus respectivas respuestas para completar la l\u00f3gica de negocio que precisase para realizar la venta. En la imagen de la derecha, vemos el poder de la facade en acci\u00f3n, esta facade ahora tiene el acoplamiento hacia las clases que necesitase para completar la venta y ofrece a las clases de venta una abstracci\u00f3n a trav\u00e9s de una interfaz simplificada para hacer uso de ella. En este escenario, facade tambi\u00e9n habilita la reutilizaci\u00f3n; sin embargo, a pesar de conseguirlo este no es su prop\u00f3sito principal.<\/p>\n\n\n\n

Debe quedar claro que el acoplamiento que existe para realizar la venta NO desaparece del proyecto, dicho acoplamiento sigue existiendo pero ahora en la facade.<\/p>\n\n\n\n

Facade en nuestra estructura del proyecto<\/h2>\n\n\n\n

Facade est\u00e1 para ofrecer una interfaz simplificada a una l\u00f3gica de negocio y NO para ser parte de una estructura de paquetes dentro de la arquitectura del proyecto a nivel de vista de paquetes. 
<\/p>\n\n\n

\n
\"\"
Uso incorrecto de facade<\/figcaption><\/figure><\/div>\n\n\n

La imagen anterior muestra un cl\u00e1sico uso incorrecto de facade donde la presentan como una capa dentro de la estructura del proyecto, cuando ya hemos explicado realmente cual es su prop\u00f3sito. Veamos una aproximaci\u00f3n m\u00e1s correcta de su uso.<\/p>\n\n\n

\n
\"\"
Una vista de nuestro proyecto usando correctamente facade<\/figcaption><\/figure><\/div>\n\n\n

Las Facades hacen parte de la l\u00f3gica de negocio y por lo tanto, deben estar dentro de la carpeta service podr\u00edas llegar a crear una carpeta para dejar todas tus facades dependiendo de la necesidad que tenga tu proyecto.<\/p>\n\n\n\n

\u201cToda la arquitectura habla de dise\u00f1o, pero no todo el dise\u00f1o habla de arquitectura\u201d<\/h3>\n\n\n\n

Cuando se habla de Facade entonces estamos hablando de dise\u00f1o y no de arquitectura de software debemos recordar que La arquitectura de software habla de la forma que se le da al sistema, esa forma es la divisi\u00f3n del sistema en componentes, la organizaci\u00f3n (estructuctura) de esos componentes y la forma en que esos componentes se comunican entre s\u00ed.<\/em><\/p>\n\n\n\n

SOLID y Facade<\/h2>\n\n\n\n

Algunas personas piensan que facade, al \u2018disminuir\u2019 el acoplamiento (cuesti\u00f3n que no es as\u00ed como ya se explic\u00f3 anteriormente), ayuda a cumplir los principios SOLID. Esto es falso, el alto o bajo acoplamiento no es un principio SOLID. Sin embargo, revisemos c\u00f3mo se relaciona este patr\u00f3n de dise\u00f1o con SOLID:<\/p>\n\n\n\n