Patrones de diseño

Los patrones de diseño no son nuevos dentro del mundo del desarrollo de sistemas, ya que datan de 1994, cuando un grupo comúnmente denominado Gang of four, publico su libro denominado: Design Patterns: Elements of Reusable Object-Oriented Software.

Cada día que pasa van cobrando mayor importancia en el desarrollo de sistemas, las aplicaciones creadas para el iPad son un ejemplo actual de esto…

Adaptaciones

Como muchos otros que han aprovechado estas definiciones, Cocoa no es la excepción, ya que ha llevado a cabo adaptaciones específicas a su arquitectura o para poder cumplir con las capacidades del lenguaje que se emplea para codificar las aplicaciones: Objetive-C.

Para poder escribir código exitosamente en XCode, debemos conocer los patrones empleados en el SDK; desde luego esto se sale desproporcionadamente de los alcances que tiene este Blog, puesto que no voy a repetir lo que podemos encontrar en muchos lugares en Internet.

Así que me voy a limitar a presentarles una lista de todos estos patrones, con la fuerte recomendación de que investigue para que lean y comprendan sus alcances y limitaciones.

Sobre todo, porque en este momento soy un humilde aprendiz de esta plataforma al igual que ustedes. En lo personal mi experiencia previa usando estos patrones se ha desarrollado en la plataforma de Microsoft, es ahí donde los he usado y hasta he escrito y ejemplificado algunos de estos patrones en mi otro Blog donde hablo de arquitectura de software para ASP.NET. Si saben de .NET pueden buscar estos patrones en ese sitio y hacerse una idea con ejemplos muy sencillos donde podemos ver cómo fueron aplicados.

 

Patrones que deben conocer y comprender.

Esta lista incluye una muy breve descripción de cada uno, espero que en transcurso de la vida de este Blog, les pueda proporcionar ejemplos reales, para que terminen de comprenderlos; en este momento creo que con saber lo que hay detrás de cada uno, será suficiente para poder emprender esta aventura:

Abstract Factory

Este patrón establece los lineamientos para poder crear objetos sin la necesidad de una referencia, lo que favorece la independencia de las clases y permite escribir código que no sea cohesivo.

Adapter

Por medio de la adopción de este patrón, podemos hacer la conversión de una interface en otra que la clase cliente espera recibir. Refuerza el código no cohesivo.

Chain of responsibility

Este patrón, es un verdadero ejemplo de trabajo en equipo dentro de la programación, ya que permite que una solicitud pueda pasar entre un conjunto de objetos, hasta que alguno atienda dicha solicitud.

Command

Al aplicar este patrón podemos crear colecciones de solicitudes de acciones, al mismo tiempo que logramos la separación entre el objeto que solicita y el objeto que lleva a cabo la acción.

Composite

Para los lenguajes con componentes visuales, se requiere alguna forma de organizar y controlar los elementos de tal forma que podamos identificar su ubicación dentro de un esquema jerárquico. Este patrón de diseño nos facilita el trato a estos objetos, ya sea de forma individual como en conjunto.

Decorator.

El mayor dolor de cabeza de un programador, se presenta cuando debe agregar funcionalidad extra a un objeto que se ha liberado, el deseo más grande seria poder agregar funcionalidad extra sin tener que modificar el código. Usando este patrón podemos añadir nuevas responsabilidades sin tener que modificar el código.

Façade

En aplicaciones con un gran número de clases y funcionalidades, siempre se requiere algún medio que simplifique el trato hacia adentro de la biblioteca; este patrón provee una interface unificada de alto nivel, que nos permite encapsular y simplificar la comunicación con los demás sub sistemas.

Iterator

El patrón de diseño Iterator, provee una forma de accede a objetos que por lo general se encuentran agrupados en una colección, transfiriendo la responsabilidad de todo el control a una clase que nos ofrece una única interface para llevar a cabo acciones sobre esos objetos.

Mediator

La definición del nombre significa mediador; este patrón define un objeto que encapsula la forma en que otros dos objetos interactúan entre si; por medio de esta clase mediadora, las clases que interactúan se mantienen independientes. Toda la complejidad de esta relación se encuentra en la clase mediadora.

Memento

Al aplicar este patrón podemos exponer el estado interno de un objeto, sin violar la regla de encapsulación; al emplearlo podemos restaurar el estado de un objeto a un momento previo, como se hace con los botones de “deshacer” en las aplicaciones.

Observer.

A pesar de ser un patrón que emplea la cohesión entre las clases, el objetivo final bien lo justifica, puesto que este patrón nos permite llevar a cabo la modificación de un grupo de objetos de acuerdo a cambios realizados en otro, lo que crea una relación uno a muchos. Lo interesante de este patrón es que esta relación se puede llevar a cabo sin que los objetos tengan que conocer a los otros.

Proxy

Se dice que este patrón es muy similar al patrón Decorator, puesto que nos permite crear un objeto por medio del cual podemos controlar a otro; la diferencia radica en la funcionalidad, ya que el primero agrega funcionalidad nueva, mientras que el proxy solo controla el acceso al objeto.

Recepcionist

Aun que debo reconocer que se trata de un patrón que no se encuentra enlistado entre los originales, es muy útil para rebotar acciones a otro contexto para su atención. Se crea por la combinación de otros patrones que hemos comentado: Command, Memo y Proxy.

Singleton

Su principal objetivo es asegurarnos que una clase solo pueda crear una única instancia de sí misma, además nos provee de un acceso universal a esta, llevando a cabo todo el control de la misma.

MVC

En esta lista no podía faltar el patrón que establece la forma de comunicación entre los diferentes roles de nuestra aplicación. Son muchos los beneficios que nos proporciona la adopción de este patrón en nuestro código. Con este trabajaremos mucho en los ejemplos.

 

Comentario final

Me imagino que a este punto han de estar un poco inquietos por escribir código, lo mismo me pasa a mí, sin embargo nos falta muy poco de teoría para poder poner manos a la obra, tengan paciencia.

Frases de manzanas: Did perpetual happiness in the Garden of Eden maybe get so boring that eating the apple was justified?  Chuck Palahniuk