Los Patrones De Diseño

JOSE GREGORIO SUAREZ P. C.I. Nº 8724285 28/11/09 • •

Patrones de diseño, componentes, diseño de interfases del sistema, notación de diseño. Medición de los atributos del diseño.

MI COMENTARIO: (ANALISIS) PATRON DE DISEÑO: DE ACUERDO A LAS SIGUIENTES DEFINICIONES, ENTIENDO QUE UN PATRON DE DISEÑO: es o son soluciones comunes a problemas de diseño de software orientado a objetos y que además poseen ciertas características de efectividad para resolver ese problema, reusabilidad: que puede ser reutilizado o aplicado en otros diseños o problemas, si se quiere. http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php

Según el libro "Design Patterns ", escrito por los que comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro"). Los patrones de diseño se clasifican en: • Patrones de creación: Inicialización y configuración de objetos. • Patrones estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes. • Patrones de comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

1Un componente es una parte no trivial, casi independiente, y reemplazable de un sistema que llena claramente una funcionalidad dentro de un contexto en una arquitectura bien definida. Un componente se conforma y provee la realización física por medio de un conjunto de interfaces.[5] 2• Un componente de software en tiempo de ejecución es un paquete dinámicamente vinculado con uno o varios programas manejados como una unidad y que son accedidos mediante interfaces bien documentadas que pueden ser descubiertos en tiempo de ejecución.[6] 3• Un componente de software es una unidad de composición con interfaces contractualmente especificadas y explícitas sólo con dependencias dentro de un contexto. Un componente de software puede ser desplegado independientemente y es sujeto a la composición de terceros.[7]

4• Un Componente de Negocio representa la implementación de software del concepto de un negocio “autónomo” o un proceso de negocio. Que consiste de artefactos de software necesarios para expresar, implementar y poner en marcha el concepto de elemento reusable de un sistema mas grande de negocios.[8] Estas definiciones no son mutuamente excluyentes, por el contrario, se complementan y construyen el significado no sólo de componente, también el significado del desarrollo basado en componentes. Sin embargo más allá de su definición existen algunas características claves para que un elemento pueda ser catalogado como componente: 1– Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios y que permita su clasificación. 2– Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado. 3– Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore. 4– Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación. 5– Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.

1– Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc. 2– Es genérico: Sus servicios debe servir para varias aplicaciones. 3– Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación. 4– Independiente de la plataforma: Hardware, Software, S.O.[9]

UN COMPONENTE DE SOFTWARE: http://pegasus.javeriana.edu.co/~jcpymes/Docs/DSBC.pdf • •

•

Un componente de software reutililizable (CSR) es un artefacto de software auto-contenido y claramente identificable que:  ejecuta funciones específicas,  tiene una interface clara a través de la cual se integra a otros sistemas,  tiene una documentación apropiada y  tiene un status de reuso definido Un componente de software reutilizable puede ser:  un módulo,  una clase,  un procedimiento o función,  un subsistema,  una aplicación

Los patrones de diseño (design patterns) son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias. http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o Patrones de diseño o más comúnmente conocidos como "Design Patterns". ¿Qué son los patrones de diseño? Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.

Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso. En este artículo presentamos una lista con los más comunes y conocidos. Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos. A continuación una lista con los patrones de diseño a objetos más habituales publicados en el libro "Design Patterns ", escrito por los que comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro").

Patrones de creación

• • • • •

Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas. Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones. Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos. Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo. Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.

Patrones estructurales

• • • • • • •

Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles. Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente. Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos. Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad. Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar. Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente. Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento

•

Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.

•

Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones. Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje. Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna. Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente. Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde. Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos. State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto. Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan. Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura. Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.

• • • • • • • • •

http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php

Volver

Qué es un Patrón de Diseño? Por Nicolás Tedeschi

Contenido ¿Qué es un Patrón de Diseño? Patrones Creacionales Patrones Estructurales Patrones de Comportamiento Conclusión

¿Qué es un Patrón de Diseño? Esta fue la primer pregunta que me hice cuando comencé a investigar sobre este tema. Al principio no tenía mucha idea de por dónde comenzar, por lo que mi primera reacción fue realizar una búsqueda en Internet y obtener de esta manera alguna base sobre la cual apoyarme. La definición que más me gustó fue la siguiente: “Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios). Grande fue mi sorpresa al averiguar que existen varios patrones de diseño popularmente conocidos, los cuales se clasifican como se muestra a continuación:

•

Patrones Creacionales: Inicialización y configuración de objetos.

•

Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.

•

Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

Veamos un poco en qué consisten los distintos tipos de patrones, cuáles son sus fines y qué beneficios nos aportan.

Patrones de diseño software Ramiro Lago (Abril 2007)

Introducción El diseño es un modelo del sistema, realizado con una serie de principios y técnicas, que permite describir el sistema con el suficiente detalle como para ser implementado. Pero los principios y reglas no son suficientes, en el contexto de diseño podemos observar que los buenos ingenieros tienen esquemas y estructuras de solución que usan numerosas veces en función del contexto del problema. Este es el sentido cabal de la expresión "tener un mente bien amueblada", y no el significado de tener una notable inteligencia. Estos esquemas y estructuras son conceptos reusables y nos permiten no reinventar la rueda. Un buen ingeniero reutiliza un esquema de solución ante problemas similares.

Algo de historia El concepto de "patrón de diseño" que tenemos en Ingeniería del Software se ha tomado prestado de la arquitectura. En 1977 se publica el libro "A Pattern Language: Towns/Building/Construction", de Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King y Shlomo Angel, Oxford University Press. Contiene numerosos patrones con una notación específica de Alexander. Alexander comenta que “Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más de un millón de veces sin hacerlo siquiera dos veces de la misma forma”. El patrón es un esquema de solución que se aplica a un tipo de problema, esta aplicación del patrón no es mecánica, sino que requiere de adaptación y matices. Por ello, dice Alexander que los numerosos usos de un patrón no se repiten dos veces de la misma forma. La idea de patrones de diseño estaba "en el aire", la prueba es que numerosos diseñadores se dirigieron a aplicar las ideas de Alexander a su contexto. El catálogo más famoso de patrones se encuentra en “Design Patterns: Elements of Reusable ObjectOriented Software”, de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, 1995, Addison-Wesley, también conocido como el libro GOF (Gang-Of-Four). Siguiendo el libro de GOF los patrones se clasifican según el proposito para el que han sido definidos: • • •

Creacionales: solucionan problemas de creación de instancias. Nos ayudan a encapsular y abstraer dicha creación. Estructurales: solucionan problemas de composición (agregación) de clases y objetos. De Comportamiento: soluciones respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos que encapsulan. Según el ámbito se clasifican en patrones de clase y de objeto:

Clase

Objeto

Creación Método de Fabricación

Fábrica, Constructor, Prototipo, Singleton

Estructural Adaptador (clases)

De Conducta Interprete Plantilla Cadena de Adaptador Responsabilidad, (objetos), Puente, Comando (orden), Composición, Iterador, Decorador, Intermediario, Fachada, Observador, Estado, Flyweight Estrategia, Visitante, Memoria

Concepto de patrón de diseño "Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad de un sistema orientado a objetos se mide por la atención que los diseñadores han prestado a las colaboraciones entre sus objetos. Los patrones conducen a arquitecturas más pequeñas, más simples y más comprensibles". (Grady Booch) Los patrones de diseño son descripciones de clases cuyas instancias colaboran entre sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso debemos especificar: • • • • • • • • •

Nombre Propósito o finalidad Sinónimos (otros nombres por los que puede ser conocido) Problema al que es aplicable Estructura (diagrama de clases) Participantes (responsabilidad de cada clase) Colaboraciones (diagrama de interacciones) Implementación (consejos, notas y ejemplos) Otros patrones con los que está relacionado Ventajas de los patrones:

La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada. Cada patrón permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento. Un patrón es un esquema o microarquitectura que supone una solución a problemas (dominios de aplicación) semejantes (aunque los dominios de problema pueden ser muy diferentes e ir desde una aplicación CAD a un cuadro de mando empresarial). Interesa constatar una vez más la vieja distinción entre dominio del problema (donde aparecen las clases propias del dominio, como cuenta, empleado, coche o beneficiario) y el dominio de la solución o aplicación (donde además aparecen clases como ventana, menú, contenedor o listener). Los patrones son patrones del dominio de la solución. También conviene distinguir entre un patrón y una arquitectura global del sistema. Por decirlo en breve, es la misma distancia que hay entre el diseño de un componente (o módulo) y el análisis del sistema. Es la diferencia que hay entre el aspecto micro y el macro, por ello, en ocasiones se denomina a los patrones como "microarquitecturas". En resumen, un patrón es el denominador común, una estructura común que tienen aplicaciones semejantes. Esto también ocurre en otros ordenes de la vida. Por ejemplo, en nuestra vida cotidiana aplicamos a menudo el esquema saludo-presentación-mensajedespedida en ocasiones diversas, que van desde un intento de ligar hasta dar una conferencia (si todavía no cree que existan patrones o que no son útiles intente ligar con el esquema despedida-mensaje-presentación-saludo, a ver que ocurre).

Algunos patrones de diseño Delegado (Delegate) Compuesto (Composite) Decorador (Decorator) Mediador (Mediator) Iterador (Iterator) Observador (Observer) Modelo-vista-controlador (Model-View-Controller) Factoria Data Access Object (DAO) Proxy

Volver al índice