Padrón de deseño

Os padróns de deseño son a base para a procura de solucións a problemas comúns no desenvolvemento de software e outros ámbitos referentes ó deseño de interacción ou interfaces.

Un padrón de deseño é unha solución a un problema de deseño. Para que unha solución sexa considerada un padrón debe posuír certas características. Unha delas é que debeu comprobarse a súa efectividade resolvendo problemas similares en ocasións anteriores. Outra é que debe ser reempregable, o que significa que é aplicable a diferentes problemas de deseño en distintas circunstancias.

Breve apuntamento histórico

En 1979 o arquitecto Christopher Alexander proporcionou ó mundo da arquitectura o libro The Timeless Way of Building; nel propoñía a aprendizaxe e uso dunha serie de padróns para a construción de edificios dunha maior calidade.

En palabras deste autor "cada padrón describe un problema que ocorre infinidade de veces no noso contorno, así como a solución ó mesmo, de tal xeito que podemos utilizar esta solución un millón de veces más adiante sen ter que volver a pensala outra vez".

Os padróns que Christopher Alexander e os seus colegas definiron, publicados nun volume denominado A Pattern Language, son unha tentativa de formalizar e plasmar dun xeito práctico xeracións de coñecemento arquitectónico. Os padróns non son principios abstractos que requiran o seu redescubrimento para obter unha aplicación satisfactoria, nin son específicos a unha situación particular ou cultural; son algo intermedio. Un padrón define unha posible solución correcta para un problema de deseño dentro dun contexto dado, describindo as calidades invariantes de todas as solucións.

Máis tarde, en 1987, Ward Cunningham e Kent Beck empregaron varias ideas de Alexander para desenvolveren cinco padróns de interacción home-ordenador (HCI) e publicaron un artigo en OOPSLA-87 titulado Using Pattern Languages for OO Programs.

Non obstante, non foi ata comezos da década de 1990 cando os padróns de deseño tiveron un gran éxito no mundo da informática a partir da publicación do libro Design Patterns escrito polo grupo Gang of Four (GoF) composto por Erich Gamma, Richard Helm, Ralph Johnson e John Vlisides, no que se recollían 23 padróns de deseño comúns.

Obxectivos dos padróns

Os padróns de deseño pretenden:

Proporcionar catálogos de elementos reempregables no deseño de sistemas software.
Evitar a reiteración na procura de solucións a problemas xa coñecidos e solucionados con anterioridade.
Formalizar un vocabulario común entre deseñadores.
Estandarizar o xeito en que se realiza o deseño.
Facilitar a aprendizaxe das novas xeracións de deseñadores condensando coñecemento xa existente.

Así mesmo, non pretenden:

Impoñer certas alternativas de deseño no canto doutras.
Eliminar a creatividade inherente ó proceso de deseño.

Non é obrigatorio empregar os padróns, só é aconsellable no caso de ter o mesmo problema ou similar que soluciona o padrón, sempre tendo en conta que nun caso particular pode non ser aplicable. "Abusar ou forzar o uso dos padróns pode ser un erro".

Categorías de padróns

Segundo a escala ou nivel de abstracción:

Padróns de arquitectura: Aqueles que expresan un esquema organizativo estrutural fundamental para sistemas de software.
Padróns de deseño: Aqueles que expresan esquemas para definir estruturas de deseño (ou as súas relacións) coas que construír sistemas de software.
Dialectos: padróns de baixo nivel específicos para unha linguaxe de programación ou contorno concreto.

Ademais, tamén é importante apuntar o concepto de "antipadrón de deseño", que con forma semellante á dun padrón, tenta previr contra erros comúns de deseño no software. A idea dos antipadróns é dar a coñecer os problemas que carrexan certos deseños moi frecuentes, para tentar evitar que diferentes sistemas acaben unha e outra vez no mesmo final morto por cometer os mesmos erros.

Ademais dos padróns xa vistos, actualmente existen outros padróns como o seguinte:

Interacción: Son padróns que nos permiten o deseño de interfaces web.

Estruturais ou modelos de padróns

Para describir un padrón úsanse modelos máis ou menos estandarizados, de xeito que se expresen uniformemente e poidan constituír efectivamente un medio de comunicación uniforme entre deseñadores. Varios autores eminentes nesta área propuxeron modelos lixeiramente distintos, se ben a maioría definen os mesmos conceptos básicos.

O modelo máis común é o empregado precisamente polo GoF e consta dos seguintes apartados:

Nome do padrón: nome estándar do padrón polo cal será recoñecido na comunidade (normalmente exprésanse en inglés).
Clasificación do padrón: creacional, estrutural ou de comportamento.
Intención: ¿Que problema pretende resolver o padrón?
Tamén coñecido como: Outros nomes de uso común para o padrón.
Motivación: Escenario de exemplo para a aplicación do padrón.
Aplicabilidade: Usos comúns e criterios de aplicabilidade do padrón.
Estrutura: Diagramas de clases oportunos para describir as clases que interveñen no padrón.
Participantes: Enumeración e descrición das entidades abstractas (e os seus roles) que participan no padrón.
Colaboracións: Explicación das interrelacións que se dan entre os participantes.
Consecuencias: Consecuencias positivas e negativas no deseño derivadas da aplicación do padrón.
Implementación: Técnicas ou comentarios oportunos de cara á implementación do padrón.
Código de exemplo: Código fonte exemplo de implementación do padrón.
Usos coñecidos: Exemplos de sistemas reais que usan o padrón.
padróns relacionados: Referencias cruzadas con outros padróns.

Relación de principais padróns GoF (Gang Of Four)

padróns creacionais

Object Pool (Conxunto de Obxectos): (Non pertence ós padróns especificados por GoF) Obtéñense obxectos novos a través da clonación. Empregado cando o custo de crear unha clase é maior que o de clonala. Especialmente con obxectos moi complexos. Especifícase un tipo de obxecto a crear e emprégase unha interface do prototipo para xerar un novo obxecto por clonación. O proceso de clonación iníciase instanciando un tipo de obxecto da clase que queremos clonar.
Abstract Factory (Fábrica abstracta): Permite traballar con obxectos de distintas familias de xeito que estas non se mesturen entre si e facendo transparente o tipo de familia concreta que se estea empregando.
Builder (Construtor virtual): Abstrae o proceso de creación dun obxecto complexo, centralizando dito proceso nun único punto.
Factory Method (Método de fabricación): Centraliza nunha clase construtora a creación de obxectos dun subtipo dun tipo determinado, ocultando ó usuario a casuística para elixir o subtipo que crear.
Prototype (Prototipo): Crea novos obxectos clonándoos dunha instancia xa existente.
Singleton (Instancia única): Garante a existencia dunha única instancia para unha clase e a creación dun mecanismo de acceso global a dita instancia.

padróns estruturais

Adapter (Adaptador): Adapta unha interface para que poida ser empregada por unha clase que doutro xeito non podería empregala.
Bridge (Ponte): Separa unha abstracción da súa implementación.
Composite (Obxecto composto): Permite tratar obxectos compostos coma se se tratase dun simple.
Decorator (Envoltorio): Engade funcionalidade a unha clase dinamicamente.
Facade (Fachada): Prové dunha interface unificada simple para acceder a unha interface ou grupo de interfaces dun subsistema.
Flyweight (Peso lixeiro): Reduce a redundancia cando gran cantidade de obxectos posúen idéntica información.
Proxy: Mantén un representante dun obxecto.

padróns de comportamento

Chain of Responsibility (Cadea de responsabilidade): Permite establecer a liña que deben levar as mensaxes para que os obxectos realicen a tarefa indicada.
Command (Orde): Encapsula unha operación nun obxecto, permitindo executar dita operación sen necesidade de coñecer o contido da mesma.
Interpreter (Intérprete): Dada unha linguaxe, define unha gramática para dita linguaxe, así como as ferramentas necesarias para interpretala.
Iterator (Iterador): Permite realizar percorridos sobre obxectos compostos independentemente da implementación destes.
Mediator (Mediador): Define un obxecto que coordine a comunicación entre obxectos de distintas clases, pero que funcionan como un conxunto.
Memento (Recordo): Permite volver a estados anteriores do sistema.
Observer (Observador): Define unha dependencia dun-a-moitos entre obxectos, de xeito que cando un obxecto cambie de estado se notifique e actualicen automaticamente tódolos obxectos que dependen del.
State (Estado): Permite que un obxecto modifique o seu comportamento cada vez que cambie o seu estado interno.
Strategy (Estratexia): Permite dispoñer de varios métodos para resolver un problema e elixir cal empregar en tempo de execución.
Template Method (Método modelo): Define nunha operación o esqueleto dun algoritmo, delegando nas subclases algúns dos seus pasos. Isto permite que as subclases redefinan certos pasos dun algoritmo sen cambiar a súa estrutura.
Visitor (Visitante): Permite definir novas operacións sobre unha xerarquía de clases sen modificar as clases sobre as que opera.

padróns de interacción

A primeira tentativa por aplicar este concepto no deseño das interfaces de usuario deuse por Ward Cummingham e Kent Beck, que adaptaron a proposta de C. Alexander e crearon cinco padróns de interface: Window per task, Few panes, Standard panes, Nouns and verbs, e Short Menu. En anos máis recentes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime Muñoz desenvolveron coleccións de padróns de interacción para a World Wide Web. En ditas coleccións captan a experiencia de programadores e deseñadores expertos no desenvolvemento de interfaces empregables e condensan esta experiencia nunha serie de guías ou recomendacións, que poidan ser empregadas polos desenvolvedores novatos co propósito de que en pouco tempo adquiran a habilidade de deseñar interfaces que incidan na satisfacción dos usuarios. Os padróns de interacción procuran o reemprego de interfaces eficaces e un manexo óptimo dos recursos das páxinas web, facendo máis eficaz o consumo de tempo no deseño do sitio web e permitindo ós programadores novatos adquirir máis experiencia.

Aplicación en ámbitos concretos

Ademais da súa aplicación directa na construción de software en xeral, e derivado precisamente do gran éxito que tiveron, os padróns de deseño foron aplicados a múltiples ámbitos concretos producíndose "linguaxes de padróns" e extensos "catálogos" da man de diversos autores.

En particular son notorios os esforzos nos seguintes ámbitos:

padróns de interfaces de usuario, isto é, aqueles que intentan definir os mellores xeitos de construír interfaces home-máquina (véxase Interacción persoa-computador, Interface gráfica de usuario).
padróns para a construción de sistemas empresariais, onde se requiren especiais esforzos en infraestruturas de software e un nivel de abstracción importante para maximizar factores como a escalabilidade ou o mantemento do sistema.
padróns para a integración de sistemas (véxase Integración de aplicacións empresariais), é dicir, para a intercomunicación e coordinación de sistemas heteroxéneos.
padróns de fluxos de traballo, isto é, para a definición, construción e integración de sistemas abstractos de xestión de fluxos de traballo e procesos con sistemas empresariais. Véxase tamén BPM.

Véxase tamén

Bibliografía

Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)
A System of Patterns - Buschmann, Meunier, Rohnert, Sommerlad, Stal - Wiley
UML y Patrones. Introducción al análisis y diseño orientado a objetos - Larman - Prentice Hall
AntiPatterns. Refactoring Software, Architectures and Projects in Crisis - Brown, Malveau, McCormick Mowbray - Wiley
Patterns in Java - Mark Grand - Wiley
EJB Design Patterns - Floyd Marinescu - Wiley
Head First Design Patterns - O'Reilly

Ligazóns externas

Portland Pattern Repository