bitácora de uno

Antes de ir al grano tengo que decir escribir que le he cogido un poco de manía al concepto de Patrones de Diseño mal aplicado. Por lo que he leído da la impresión de que como es muy chuli esto de los patrones, se fuerza a que cualquier cosa o idea luzca las palabras en su descripción. Efectivamente podemos ver un patrón en cómo removemos el azúcar del café, pero si así lo percibimos en este caso ¿en qué situación no los veremos? Me da la sensación que de esta forma pierden su cometido y, cuando menos, su particularidad.

Christopher Alexander, arquitecto de edificios reconocido como el originador de la idea de los patrones, explica que “cada patrón en una regla con tres integrantes que expresa la relación entre cierto contexto, un problema y una solución a dicho problema”.

Un desarrollador de midlewares, frameworks o aplicaciones específicas se tiene que enfrentar a retos relacionados con el diseño y la programación de asuntos tales como:
La persistencia de los datos, la organicación de los datos, la gestión de las conexiones, inicialización de servicio y objetos, el manejo de los parámetros de configuración, la comunicación entre estructuras, la concurrencia, el control de acceso a los recursos, control del flujo de programa, la gestión de errores y de información de log, bucles de gestión de eventos, etc.

La resolución de estos retos se presenta una y otra vez, e inicialmente el conocimiento necesario para resolverlos estaba en las mentes de algunos desarrolladores o, de forma implícita y poco aprehendible, en el código. Los patrones de diseño tratan de solventar este problema.

Los patrones permiten la reutilización de los conocimientos y experiencia de diseño implementando los aspectos estáticos y dinámicos de soluciones satisfactorias a problemas que surgen al desarrollar software en un contexto determinado. De esta forma ayudan a incrementar la reusabilidad capturando y reutilizando las estructuras y las formas de colaboración de los elementos clave de undiseño software.

Se ha realizado un gran esfuerzo para documentar patrones y en el desarrollo de frameworks basados en ellos que permitan a su vez el desarrollo y la reutilización de middlewares.

Patrones de Diseño:
Proporcionan un esquema con los elementos de un sistema software y las relaciones entre ellos y describen una estructura dfe elementos en comunicación que soluciona un problema de diseño general en un contexto particular.

Patrones de Arquitectura:
Expresan la estructura fundamental de organización de un software y proporcionan un conjunto de subsistemas con sus responsabilidades, y las líneas para organizar la relación entre dichos subsistemas.

Lenguajes de Patrones:
Agrupan una trama de patrones para definir un vocabulario para hablar de problemas de desarrollo y ofrecer un proceso para su resolución. Un grupo de desarrolladores trabajando en un software y hablando de los problemas que se les presentan y las soluciones más acertadas y que se preocupen por leer lo que hay por ahí en patrones y software, acabarán incorporando a sus conversaciones los nombres de los patrones más utilizados y entendiendo como grupo, sus aplicaciones y las relaciones entre ellos. Estará bien trabajar en un grupo así usando un lenguaje de patrones ¿no?.

Podíamos decir que los patrones son descripciones más abstractas que los frameworks ya que éstos están implementados en un lenguaje en particular. En general los frameworks albergan e implementan docenas de patrones de diseño, y a su vez los patrones se utilizan a menudo para documentar los frameworks.

Veremos algún patrón, junto con su aplicación y ejemplo de uso en nuevas entradas.

Mucho de lo aquí visto están en la enriquecedora página de documentación de ACE.
También puedes hurgar un rato por la Wikipedia.