| Revisión actual |
Tu texto |
| Línea 35: |
Línea 35: |
|
| |
|
| Cada patrón tiene el siguiente formato: | | Cada patrón tiene el siguiente formato: |
| * Precondición: Los patrones que deben ser satisfechos antes que dicho patrón sea válido.
| | • Precondición: Los patrones que deben ser satisfechos antes que dicho patrón sea válido. |
| * Problema: Un resumen del problema al cual está dirigido el patrón. El problema debe ser usado por el lector, para ver si el patrón es aplicable o no.
| | • Problema: Un resumen del problema al cual está dirigido el patrón. El problema debe ser usado por el lector, para ver si el patrón es aplicable o no. |
| * Restrincciones (constraints): Las restricciones describen el conflicto de cualquier solución al problema.
| | • Restrincciones (constraints): Las restricciones describen el conflicto de cualquier solución al problema. |
| * Solución: Un resumen de la solución al problema. La solución generalmente está acompañada por diagramas.
| | • Solución: Un resumen de la solución al problema. La solución generalmente está acompañada por diagramas. |
|
| |
|
| Describir una arquitectura con patrones es como el proceso de división de células y especialización que conducen al crecimiento del organismo biológico. El diseño comienza como una nube confusa que representa el sistema a realizar. Cuando los patrones se comienzan a aplicar a dicha nube, se comienza a focalizar las distintas partes del sistema. Cuando no hay más patrones a ser aplicados, el diseño está terminado. | | Describir una arquitectura con patrones es como el proceso de división de células y especialización que conducen al crecimiento del organismo biológico. El diseño comienza como una nube confusa que representa el sistema a realizar. Cuando los patrones se comienzan a aplicar a dicha nube, se comienza a focalizar las distintas partes del sistema. Cuando no hay más patrones a ser aplicados, el diseño está terminado. |
| El paper da como ejemplo de derivación de arquitecturas a través de patrones, la arquitectura de HotDraw, un framework para estructurar editores gráficos. | | El paper da como ejemplo de derivación de arquitecturas a través de patrones, la arquitectura de HotDraw, un framework para estructurar editores gráficos. |
| Para dicha arquitectura, utiliza los siguientes patrones: | | Para dicha arquitectura, utiliza los siguientes patrones: |
| *Model – View – Controler: para mostrar y manipular los dibujos en la pantalla.
| | • Model – View – Controler: para mostrar y manipular los dibujos en la pantalla. |
| *Composite: para representar el concepto de figuras.
| | • Controler: para representar el concepto de figuras. |
| *Objects of State: para representar que herramienta es seleccionada en la paleta (ya que dicho comportamiento depende del input).
| | • Objects of State: para representar que herramienta es seleccionada en la paleta (ya que dicho comportamiento depende del input). |
| *Editor: para representar que diferentes tipos de dibujos necesitarán diferentes conjuntos de herramientas.
| | • Editor: para representar que diferentes tipos de dibujos necesitarán diferentes conjuntos de herramientas. |
| *Observer: para actualizar la imagen en la pantalla cuando las figuras cambiaron su apariencia.
| | • Observer: para actualizar la imagen en la pantalla cuando las figuras cambiaron su apariencia. |
| *Collect Damage: para representar que cuando algunas partes del dibujo cambian simultáneamente, queremos que se actualicen como una unidad.
| | • Collect Damage: para representar que cuando algunas partes del dibujo cambian simultáneamente, queremos que se actualicen como una unidad. |
| *Update as User Speed: para asegurarnos que se muestren los cambios colectados con el patrón Collect Damage (región damaged).
| | • Update as User Speed: para asegurarnos que se muestren los cambios colectados con el patrón Collect Damage (región damaged). |
| *Wrapper: para manejar los “handles” de la figuras.
| | • Wrapper: para manejar los “handles” de la figuras. |
|
| |
|
| '''Conclusiones:'''
| | == Conclusiones: == |
|
| |
|
| La derivación de una arquitectura a partir de patrones es como la presentación de un teorema matemático. Comenzando con un problema a resolver, se van usando pasos conocidos para ir refinando la solución. E resultado es que no solo se entiende el sistema final sino también se entienden las razones que conducen a él. Por todo esto en sencillo para los programadores usar y extender sistema documentados con la derivación a través de patrones. | | La derivación de una arquitectura a partir de patrones es como la presentación de un teorema matemático. Comenzando con un problema a resolver, se van usando pasos conocidos para ir refinando la solución. E resultado es que no solo se entiende el sistema final sino también se entienden las razones que conducen a él. Por todo esto en sencillo para los programadores usar y extender sistema documentados con la derivación a través de patrones. |
|
| |
| == Introducción Design Patterns: Elements of Reusable Object-Oriented Software ==
| |
|
| |
|
| |
| Una cosa que saben los diseñadores experimentados es no resolver cada problema desde el principio. En lugar de eso, reusan soluciones que les funcionaron en el pasado. Cuando encuentran una buena solución, la usan una y otra vez. Esta experiencia es parte de lo que los hace expertos. Consecuentemente, encontraremos patrones recurrentes de clases y objetos comunicándose en muchos sistemas orientados a objetos. Estos patrones resuelven problemas de diseño específicos y hacen a los diseños más flexibles, elegantes y, en definitiva, reusables. Ayudan a los diseñadores a reusar diseños exitosos basando los nuevos diseños en la experiencia previa.
| |
|
| |
| Un patrón de diseño describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de una solución al problema, de modo que dicha solución pueda usarse nuevamente. En general un patrón tiene 4 elementos:
| |
|
| |
| *Nombre: En una o dos palabras se usa para describir el problema de diseño, las soluciones y las consecuencias. Nombrar un patrón incrementa nuestro vocabulario de diseño y nos permite diseñar a un mayor nivel de abstracción. Tener un vocabulario de patrones nos permite conversar sobre ellos con nuestros colegas y en la documentación.
| |
| *Problema: Describe cuando aplicar el patrón. Explica el problema y su contexto.
| |
| *Solución: Describe los elementos que hacen al diseño, sus relaciones, responsabilidades y colaboraciones. La solución no describe un diseño concreto o una implementación, ya que un patrón es como una plantilla que puede aplicarse en muchas situaciones diferentes. El patrón provee una descripción abstracta de un problema de diseño y como un conjunto general de objetos lo resuelve.
| |
| *Consecuencias: Son el resultado y los trade-offs de aplicar el patrón. Son críticas para evaluar alternativas de diseño y para entender los costos y beneficios de aplicar el patrón.
| |
|
| |
| '''Descripción de los Patrones de Diseño'''
| |
|
| |
| Para describirlos se usa un formato consistente:
| |
| *Nombre y Clasificación: El nombre del patrón transmite suscintamente la esencia del patrón. Un buen nombre es vital porque se volverá parte de nuestro vocabulario.
| |
| *Intención (Intent): Una breve oración que responde a las siguientes preguntas: ¿Qué hace el patrón? ¿Cuál es su razón e intención? ¿Que problema de diseño particular ataca?
| |
| *Also Known as (También conocido como): Otros nombres bien conocidos para el patrón.
| |
| *Motivación: Un escenario que ilustra el problema y como los objetos en el patrón lo resuelven.
| |
| *Aplicabilidad: En que situaciones puede aplicarse el patrón, que son ejemplos de diseño pobre que el patrón puede resolver, como reconocer estas situaciones.
| |
| *Estructura: Representaciones gráficas del patrón usando diagramas de clases, objetos, colaboración, etc.
| |
| *Participantes: Los objetos y clases participantes del patrón y sus responsabilidades.
| |
| *Colaboraciones: Como colaboran entre si los participantes para llevar a cabo sus responsabilidades.
| |
| *Consecuencias: ¿Como soporta el patrón sus objetivos?
| |
| *Implementación: Ayudas y técnicas a tener en cuenta para la implementación del patrón.
| |
| *Código de Ejemplo
| |
| *Usos conocidos: Ejemplos de uso encontrados en sistemas reales.
| |
| *Patrones relacionados: ¿Qué patrones están relacionados con este? ¿Cuales son las diferencias? ¿Con que otros patrones puede usarse?
| |
|
| |
| '''¿Como resuelven los problemas los patrones de diseño?'''
| |
|
| |
| *'''Encontrando los objetos apropiados''': La parte complicada del diseño orientado a objetos es descomponer un sistema en objetos. La tarea es dificil porque intervienen muchos factores: encapsulamiento, granularidad, dependencias, flexibilidad, performance, evolutibilidad, reusabilidad, etc, etc. Los patrones ayudan a identificar abstracciones no tan obvias y los objetos que pueden modelarlas.
| |
| *'''Determinando la granularidad'''
| |
| *'''Especificando las interfaces entre los objetos'''
| |
| *'''Especificando las implementaciones de los objetos''': Es imporante entender la diferencia entre la clase de un objeto y su tipo. La clase de un objeto define como se implementa el mismo. Define su estado interno y los métodos que implementan los mensajes. En contraste el tipo de un objeto solamente se refiere a su interface. Un objeto puede tener muchos tipos y objetos de clases diferentes pueden tener el mismo tipo. Cuando la herencia se usa cuidadosamente (algunos dicen que en forma apropiada), todas las clases derivadas de una clase abstracta comparten la misma interface. Hay dos beneficios de manipular los objetos únicamente en términos de interfaces definidas por clases abstractas: Los objetos cliente no se preocupan de los tipos específicos de objetos que usan mientras los mismos adhieran a la interfacen que esperan. Y tampoco se preocupan de las clases que implementan esos objetos. Esto reduce sensiblemente las dependencias de implementación entre subsistemas que lleva al siguiente principio de diseño: ''Programar para una interface y no para una implementación.''
| |
| *'''Poniendo en práctica mecanismos de reuso''': Las dos técnicas más comunes de reusar funcionalidad son la herencia de clases y la composición de objetos. El reuso por clasificación generalmente se denomina de "caja blanca". La composición de objetos es una alternativa al reuso por herencia. En este caso la nueva funcionalidad se obtiene componiendo objetos para obtener funcionalidad más compleja. La composición requiere que los objetos que se componen tengan interfaces bien definidas. Este estilo de reuso se denomina de "caja negra". La herencia de Clases tiene ciertas desventajas. Primero, no se puede cambiar la implementación heredada de clases padre en run-time porque la herencia se define en tiempo de compilación. Segundo, y generalmente peor, las clases padre a menudo definen parte de la representación de sus subclases ya que la herencia expone a las subclases detalles de la implementación de sus padres. Por otra parte la composición de objetos se define en run-time a través de objetos que obtienen referencias a otros objetos. Como los objetos se acceden únicamente a través de sus interfaces no estamos rompiendo el encapsulamiento. Cualquier objeto puede ser reemplazado por otro mientras que el mismo tenga el mismo tipo. La composición tiene otro efecto en el diseño de sistemas. Favoreciendo la composición por sobre la herencia ayuda a mantener cada clase encapsulada y enfocada en una tarea. Las clases y jerarquías se mantendrán pequeñas y será menos probable que se conviertan en monstruos inmanejables. Además un diseño basado en composición tendrá más objetos y el comportamiento del sistema dependerá de sus relaciones en lugar de estar definido en una clase. Estos nos lleva al segundo principio de diseño: ''Favorecer la composición de objetos por sobre la herencia de clases.''
| |
