Home » Guías » Patrones de diseño en software (I): Facade
Facade Swift

Patrones de diseño en software (I): Facade

¿Qué son los patrones de diseño de software? Son aquellos modelos que nos dan solución al problema de cómo enfrentar un nuevo programa o proyecto. Son las vértebras sobre las que se erigirá todo o parte de nuestro proyecto. Y por eso son extremadamente importantes y vamos a dedicarles una serie de guías en los próximas semanas. Y no solo hablaremos de ellos, si no que os diremos cómo se aplican en Swift 2.

El primero del que vamos a hablar es el patrón de diseño Facade (o Fachada en español). Este modelo se basa en poner una clase principal de control como fachada de otros objetos tras estos. El objetivo es simplificar al máximo la gestión y las operaciones de diversos tipos de objetos a través de un controlador único que nos permita operaciones más simples y unificadas.

Imaginemos que tenemos 3 tipos de objetos diferentes, cada uno con sus comportamientos y atributos independientes. Normalmente crearíamos una clase con los atributos y además, tendríamos en ella determinados comportamientos implícitos a partir de sus propiedades. Por ejemplo, si queremos saber un dato de un libro, acudimos a su propiedad y si queremos dar de alta uno, usamos sus inicializadores. Pero, ¿y si queremos poner “una fachada” delante de todo esto que además, nos permita almacenar los diferentes objetos en una estructura?

Con estos tres structs que hemos creado, tendríamos datos independientes para cada elemento: n elementos de libros, x de películas, y de música… cada uno independiente y con su propia entidad lo cual podría ser un problema a la hora de organizarlos. Pero ¿y si ponemos delante una fachada?.

Vamos a crear una clase biblioteca, donde tendremos almacenados tantos libros, películas y músicas como queramos, siempre en un mismo objeto o contenedor, pero que a su vez nos brinda la posibilidad de crear nuevas bibliotecas porque tal vez nuestro usuario quiera tener una para él, otra para su hermano, otra para otro miembro de la familia…

[pullquote align=”full” cite=”La clave del patrón Facade es abstraer los atributos y comportamientos de un modelo de datos dentro de una clase única que actúa de fachada” link=”” color=”blue” class=”” size=”18″][/pullquote]

Pero el método Facade no se queda ahí. También debemos hacer que las operaciones convencionales se hagan a través de esta fachada, por lo que en realidad ni nos interesa ni nunca manejaremos de manera directa los structs que dan estructura de datos a nuestro programa. Lo haremos todo a través de esta fachada.

De esta forma, si queremos crear una nueva película, música o libro, lo haríamos a través de nuestra fachada, la clase biblioteca, ya que esta será la encargada de todo en nuestra gestión. La existencia de los structs libro, pelicula y musica, ni nos importa ni nos interesa.

Nosotros sabemos que todo lo haremos a través de esta clase y cómo gestione estas los datos no es indiferente, porque de hecho podría ser que un futuro indeterminado, la estructura de datos que lo soporta cambiara, tuviera nuevos comportamientos, parámetros… cambiando en biblioteca el struct pertinente toda nuestra app seguiría funcionando sin problemas porque estamos abstrayendo los comportamientos y propiedades a una clase única que lo gestiona todo: a esa fachada.

Por ver más ejemplos, sería normal tener un método que nos dijera quién es el autor de un libro (método que por otro lado debería ser falible u opcional, para poder devolver nil en caso de no encontrar el valor proporcionado). Crearíamos este dentro de la clase biblioteca y le iríamos añadiendo una capa de consulta al mismo que englobaría todos los libros de la biblioteca.

Y como esta, programaríamos cualquier operación asociada a esta biblioteca para que toda ella sea manejada desde una única clase, nuestra fachada. De otra forma, tendríamos que buscar métodos para englobar instancias de cada struct y buscar un dato en muchas de ellas nos obligaría a crear un array por fuera y gestionarlo programando. De esta forma, como hemos dicho, abstraemos las propiedades y comportamientos del modelo de datos, dentro de nuestra clase fachada.

Obviamente, nuestros structs están ahí, y seguiremos pudiendo acceder a ellos dentro de nuestro proyecto. La única opción posible que tenemos para ocultarlos es hacerlos de tipo private, aunque esto los seguirá exponiendo al proyecto al que pertenezcan en sí y solo sería útil si nuestro proyecto está destinado a ser un framework, lo que sí ocultaría al proyecto que lo incorporara la capa de structs.

Y esto es básicamente este patrón de diseño: en adelante veremos otros muy interesantes como el Decorator, el famoso patrón de delegación o el omnipresente MVC. Hasta entonces, practicad, buscad más ejemplos y como decimos siempre: Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

ARKit

Analizando ARKit

Realizamos un análisis de ARKit, sus posibilidades, cómo funciona y lo comparamos con las Microsoft Hololens para ver el alcance de sus posibilidades. Un análisis en detalle incluyendo algunas pruebas en vídeo que hemos realizado mientras preparamos el curso de ARKit en Apple Coding Academy que verá la luz en septiembre, una vez tengamos versión final de esta interesante plataforma.

  • Raul Pairó Ferrer

    Sublime ????

  • pagly

    Me parece una gran idea darle un vistazo a los patrones. En espera del siguiente! 😛

  • Hernandez Mario

    Tuve la suerte de encontrarme con este articulo para entender un poco más los patrones y ha sido de gran ayuda