1 / 47

Patrones de diseño

Patrones de diseño. Dr. Pedro Mejia Alvarez CINVESTAV-IPN, Mexico. Origen de los Patrones. Arq. Cristopher Alexander, 70’s Ward Cuningham y Kent Beck 1987 Erich Gamma, Richard Helm, Ralph Johonson y Hohn Vissides ( el grupo de los cuatro ) 1990/1994. ¿Que es un patron?.

janet
Download Presentation

Patrones de diseño

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Patrones de diseño Dr. Pedro Mejia Alvarez CINVESTAV-IPN, Mexico

  2. Origen de los Patrones • Arq. Cristopher Alexander, 70’s • Ward Cuningham y Kent Beck 1987 • Erich Gamma, Richard Helm, Ralph Johonson y Hohn Vissides (el grupo de los cuatro) 1990/1994

  3. ¿Que es un patron? Cada Patrón es una regla de tres partes, la cual expresa una relación entre un cierto contexto, un problema y una solución. Alexander Christopher.

  4. Características de los Patrones • Proporcionan Soluciones concretas • Proporcionan soluciones técnicas • Se utilizan en situaciones frecuentes • Favorece la reutilización de código • El uso de un patrón no se refleja en el código • Es difícil reutilizar la Implementación de un patrón

  5. Patrones Los patrones reciclan ideas, no código.

  6. Clasificación de Patrones • Según su etapa de desarrollo • Análisis • Arquitectura • Diseño

  7. Patrones de Diseño • Los patrones de diseño, ayudan a diseñar soluciones de software, definiendo comportamientos comunes que suelen encontrarse en distintos componentes de software

  8. Clasificación de patrones de diseño • Según su propósito • fundamentales • creación • Descomposición • Estructurales • Comportamiento • Concurrencia

  9. Patrones de Diseño Descripción de algunos de los patrones de diseño mas importantes.

  10. Patrones Fundamentales Patrones de diseño básicos, ya que son muy usados para la representación de otros patrones.

  11. Delegación - Delegation (1) • Indica cuando no usar herencia. • Es una forma de extender la funcionalidad de una clase, pero no se desea tener una jerarquía del tipo “es un”.

  12. Ejemplo de delegación

  13. Interfaz – Interfaz (1) • Permite a una clase usar datos y servicios provistos por otras clases independientes proveyendo un acceso uniforme.

  14. Interfaz – Interfaz (2)

  15. Inmutable - Inmutable • Evita que se modifique el estado de la clase. • Es un patrón fundamental de concurrencia. • Reduce el costo de los accesos concurrentes • Evita la necesidad de sincronizar threads.

  16. Proxy - Proxy (1) • Se requiere que las llamadas a métodos de un objeto ocurran indirectamente a través de un objeto sustituto del objeto original, delegando luego las llamadas a los métodos de los objetos respectivos. • El objeto proxy, comparte la misma interfaz o superclase que el objeto delegado.

  17. Proxy - Proxy (2)

  18. Patrones de creación Abstraen comportamientos referentes a la forma como se deben crear los objetos.

  19. Fabrica Abstracta -Abstract Factory (1) • Proporciona un Interfaz para crear familias de objetos sin especificar su clase de forma concreta. • Si deseamos que nuestro software funcione sobre distintos recursos debemos abstraer las librerías utilizadas proporcionando una Interfaz común.

  20. Fabrica Abstracta -Abstract Factory (2)

  21. Singular - Singleton • Este patrón asegura que sólo una instancia de la clase sea creada. • Todos los objetos que usan una instancia de esa clase, usan la misma instancia.

  22. Patrones de descomposición Los patrones de descomposición proveen ayuda para descomponer actores y conceptos complejos en múltiples clases

  23. Compuesto - Composite (1) • También conocido como composición recursiva. • Permite construir objetos complejos mediante composición recursiva de objetos similares, en forma de árbol. • También permite manipular consistentemente los objetos en el árbol, pidiendo que todos los objetos en el árbol tengan una superclase o interfaz común.

  24. Compuesto - Composite (2)

  25. Ejemplo de Composite

  26. Patrones Estructurales describen las formas comunes en que distintos tipos de objetos pueden ser organizados para trabajar y colaborar entre ellos.

  27. Adaptador - Adapter (1) • INTENCION Convierte la interfaz de una clase en otra más compatible con nuestras necesidades. • CONOCIDO COMO Class Adapter, Object Adapter, Wrapper • MOTIVO Reduce la dependencia entre clases. • APLICACIONES • Para utilizar la interfaz de una librería que no coincide con la que se requiere. • Para extender la funcionalidad de una librería existente.

  28. Adaptador - Adapter (2) • PARTICIPANTES • Cliente Clase que hace uso de otras clases a través de un interfaz que no se tiene por que corresponder con el implementado en dichas clases. • InterfazObjetivo Clase que declara el interfaz al que llama la clase cliente. • Adaptador Clase que implementa el enlace entre el interfaz desdeado (u objetivo) y el que realmente existe (ofrecido por la ClaseExistente) • ClaseExistente Tambien llamada adaptada o adaptee, el la clase original de que se dispone.

  29. Adaptador - Adapter (3) Adaptador de Clase

  30. Adaptador - Adapter (4) Adaptador de Objeto

  31. Iterador - Iterator (1) • INTENCION Permite acceder secuencialmente a los elementos de estructura de datos u objetos preservando su estructura interna. • CONOCIDO COMO Iterator • PARTICIPANTES • IIterator: Interfaz que define los métodos de acceso a los elementos. • Iterator: Clase que implementa el acceso secuencial. • ICollection: Interfaz de la clase Collection. La clase Collection ofrece sus propios objetos Iterator especializados.

  32. Iterador - Iterator (2)

  33. Patrones de comportamiento Se utilizan para administrar y combinar ciertos comportamientos.

  34. Comando-Command (1) • Encapsula los comandos para permitir su administración si se quere: • Ejecutar asíncronamente. • Definir secuencias de ejecución • Hacer y Deshacer.

  35. Comando-Command (2)

  36. Observador-Observer (1) • Genera dependencias entre obetos, para que un componente dado (modelo) pueda informar a otros (observadores) de que su estado ha cambiado.

  37. Observador-Observer (2)

  38. Patrones de procesos Definen patrones para la definición de procesos

  39. Patrones de Procesos • Es un conjunto de tecnica, acciones y/o tareas (actividades) generales para desarrollar software orientado a objetos [Scott W. Ambler]. • Los patrones de actividad, dentro de una organización (y dentro de un proyecto) es llamado un proceso. [Coplien]

  40. Clasificación de los Patrones de Procesos • Patrones de Procesos Tareas (Task process patterns). Define pasos detallados para realizar una tarea. • Patrones de procesos de etapa (Stage process patterns). Pasos repetitivos para una simple etapa de desarrollo. • Patrones de procesos de fases (phase process patterns). Define las interaccione sentre los patrones de etapas para una simple etapa de desarrollo.

  41. Antipatrones Definen patrones que no se deben seguir.

  42. Antipatrones • Nos ofrecen una forma de resolver un problema típico, documentando lo que no se debe hace. • Nos hablan de actitudes o formas de enfrentarse a los problemas que ya sabemos suelen tener consecuencias negativas. • También reflejan experiencia, pero de este caso, de los errores cometidos.

  43. Objetivos de los Antipatrones • Dar a conocer y clasificar los errores mas comunes a la hora de desarrollar software. • Proponer un proceso para atacar esos problemas. • Evitar que se repitan constantemente. • Difundir la experiencia de otros desarrolladores.

  44. Clasificacinde los Antipatrones • Desarrollo de Software • Arquitectura de Software • Gestion de Proyectos de Software

  45. Antipatrones de Desarrollo de Software • The Blob (Clases Gigantes) • Lava Flow (Código Muerto). • Functional Decomposition (Diseño no Orientado a Objetos) • Poltergeists (No se sabe lo que hace alguna clase) • Golden Hammer (Para un martillo todos son clavos) • Spaghetti Code (Sobre anidamiento de IF’s o SWITCH’s) • Cut-and-Paste Programming (Copiar y pega código)

  46. Antipatrones de Arquitectura de software. • Stovepipe Enterprise: Aislamiento en la empresa o desarrollo de sistmas aislados y parchados • Stovepipe Systems: Sistemas que por su mala arquitectura se comportan como si sus componentes hubieran sido desarrollados por separado. • Vendor Lock-In: Arquitectura dependiente del Producto. • Architecture by implication: Arquitectura implícita. • Design by Commite: El proyecto es diseñado por un comité demasiado numerosos e inexperto. • Reinvent the Whell: Desarrollo desde cero.

  47. Antipatrones de Gestión de Proyectos de Software • Analysis paralysis: Síndrome del gran proyecto • Dirigido por una grán cantidad de personal muy inteligente. • Se identifican con nombres de gran, 2000, mega, super, etc. • Se pretende que el sistema lo haga todo • Termina cuando el proyecto se cancela

More Related