Facade pattern: interfaz unificada para proyectos de software
Equipo editorial de IONOS7 mins
El facade pattern es la solución perfecta cuando se buscan estrategias adecuadas para simplificar un software complejo. Al igual que el patrón decorador o el patrón compuesto, pertenece a la categoría de patrones estructurales de los llamados patrones de diseño GoF (abreviatura de “Gang of Four” o “Banda de los cuatro”), que han tenido una influencia decisiva en el diseño de software desde su publicación en 1994.
En este artículo, te explicamos qué es el patrón fachada y cómo ayuda a los desarrolladores en el proceso de igualar los subsistemas.
¿Qué es el facade pattern?
El patrón fachada es uno de los 23 design patterns de los GoF, que fueron publicados en 1994 por los autores Erich Gamma, Ralph Johnson, Richard Helm y John Vlissides en “Patrones de diseño: elementos de software orientado a objetos reutilizable” como guía para los desarrolladores de software. En general, estos patrones tienen como objetivo simplificar la creación de software flexibles y reutilizables. El patrón fachada define una solución modelo para una fusión simple de diferentes interfaces en sistemas complejos. Una clase de fachada universal, que también funciona como interfaz, delega importantes funcionalidades del software a los respectivos subsistemas para que el manejo de los diversos subcomponentes de un programa sea lo más sencillo posible.
¿Qué problemas soluciona el patrón fachada?
Los clientes que acceden a un subsistema complejo se refieren directamente a un gran número de objetos con interfaces completamente diferentes o dependen de estos objetos. Esto hace que la implementación, adaptación, prueba y reutilización de los clientes sea particularmente difícil para los desarrolladores. Aquí es donde el facade pattern puede ser útil.
El patrón fachada define un objeto de fachada central que:
- implementa una interfaz universal para las distintas interfaces del subsistema o subsistemas.
- y (si es necesario) puede realizar funciones adicionales antes o después de reenviar una solicitud al cliente.
Como intermediario, el objeto de fachada garantiza que el acceso y la comunicación con los componentes individuales de un subsistema se simplifiquen y se reduzca al mínimo la dependencia directa de estos componentes. Este delega las llamadas de los clientes para que éstos no necesiten conocer las clases o sus relaciones y dependencias.
Para mostrar este video, se requieren cookies de terceros. Puede acceder y cambiar sus ajustes de cookies aquí. Patrón fachada: representación en el diagrama de clase UML
La fachada o la clase de fachada es la unidad estructuradora decisiva del facade pattern. En otras palabras, su implementación y preparación es la tarea fundamental para los desarrolladores que buscan simplificar su complejo software utilizando este práctico patrón de diseño. Una vez implementado, los objetos del cliente se comunican con la clase de fachada, que en este nuevo sistema es la única instancia de la que dependen directamente los clientes.
El siguiente diagrama UML ilustra la interacción de las clases de clientes, fachada y subsistema según el patrón fachada.
Facade pattern: ventajas y desventajas
Las ventajas del facade pattern son obvias: la fachada “oculta” los subsistemas de software subyacentes y, por lo tanto, reduce la complejidad de estos sistemas. Además, el enfoque promueve el principio de acoplamiento suelto. Debido al bajo grado de interdependencia de los componentes individuales, los cambios (modificaciones, mantenimiento) son convenientes y posibles en cualquier momento. Es más, gracias al acoplamiento suelto, un subsistema es más fácil de expandir.
Si los clientes dependen del acceso directo a ciertas clases del subsistema, el acceso también puede ser otorgado en el modelo de patrón fachada. En este caso, sólo es necesario programar la visibilidad del subsistema para que un cliente pueda evitar la fachada si es necesario.
Sin embargo, el uso del patrón fachada tiene algunas desventajas. Debido a su papel central, la implementación de una fachada es una tarea tediosa y complicada, especialmente si tiene que ser insertada en un código existente. En general, la instalación de una interfaz de fachada requiere una etapa adicional indirecta, que a su vez aumenta el tiempo de computación para las llamadas de método y función, el acceso a la memoria, etc. Por último, el patrón fachada también presenta el riesgo de que el software se vuelva demasiado dependiente de la interfaz maestra central.
| Ventajas | Desventajas |
|---|---|
| Minimiza la complejidad de los subsistemas | Aplicación compleja (especialmente en un código existente) |
| Promueve el principio de acoplamiento suelto | La aproximación está acompañada por un nivel adicional de indirección |
| El software se vuelve más flexible y fácilmente expandible | Alto grado de dependencia en la interfaz de la fachada |
Casos típicos de uso del facade pattern
Las propiedades del facade pattern lo convierten en un patrón interesante para varios ámbitos de aplicación. En primer lugar, existe el deseo de una interfaz uniforme para acceder a subsistemas complejos o a cualquier número de objetos, y una fachada ayuda a simplificar las cosas en este caso. Por esta razón, el uso de la estrategia del patrón fachada desempeña un papel importante en la planificación de un proyecto.
Otra aplicación típica es el software en el que la dependencia entre los clientes y los subsistemas subyacentes debe reducirse al mínimo.
Por último, el patrón fachada es un enfoque útil para planificar proyectos de software que tienen múltiples capas. Las fachadas actúan como interfaces de comunicación entre las distintas capas, aumentando la flexibilidad y la posibilidad de ampliación y adaptación de los componentes.
Ejemplo práctico de aplicación del facade pattern
El patrón fachada está conectado a lenguajes de programación específicos. El patrón se usa típicamente con C++, C#, JavaScript, Java, PHP y Python. El siguiente ejemplo de patrón fachada está basado en Java y tomado de la página web de tutorialspoint.com.
En este ejemplo, se definirá una interfaz de aplicación universal “Shape” para los objetos que representan una forma geométrica. Además, se generan clases concretas que implementan la interfaz, así como clases de fachada llamadas “ShapeMaker”, que se encargan de delegar las consultas de los clientes.
En primer lugar, creamos la interfaz Shape.java usando el siguiente código:
public interface Shape {
void draw();
}En segundo lugar, se crean tres clases concretas que implementan la interfaz: Rectangle.java (clase para objetos rectangulares), Square.java (clase para objetos cuadrados) y Circle.java (clase para objetos redondos).
public class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}public class Square implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}public class Circle implements Shape {
@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}Por último, la clase de fachada ShapeMaker se integra en el código que será llamado por los clientes para crear las diferentes formas:
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}
