SlideShare une entreprise Scribd logo
1  sur  30
Télécharger pour lire hors ligne
Patrones de Diseño II


  “Si la depuración es el proceso de buscar y eliminar errores, entonces la programación
                           debe ser el proceso de introducirlos.”
                                       Esdger Dijkstra.


“Con el software el software en producción, la corrección de errores es como reparar un
                auto mientras está siendo conducido por la carretera.”


                                Imagemaker IT
                                                                          Agosto, 2011
Temario

•   Reutilización
•   Refactorización
•   Cuando aplicarla – Bad Smells
•   Over-Engineering
•   Facade
•   Prototype
•   Memento
•   Proxy
•   Model – View – Controller
•   Antipatrones
•   Ejemplos
Reutilización
Históricamente se ha buscado la reutilización en el desarrollo de software
Refactorización
• Es el cambio en un sistema software de tal forma
  que no se altere su comportamiento externo (no se añade
  funcionalidad) si no que mejora su estructura interna.
• Es una manera disciplinada de “limpiar” el código que
  minimiza el riesgo de introducir bugs.
• Cuando se refactoriza, se mejora el diseño que se ha escrito
  permitiendo que sea más fácil de comprender y cambiar.
• Esta se realiza a menudo como parte del proceso de
  desarrollo de SW.
• Se debe alternar el desarrollo de nuevas funcionalidades y
  casos de uso (tests) para garantizar que las mejoras no han
  alterado el comportamiento del sistema.
Cuando aplicarla – Bad Smells

•   Muchas líneas de código en las clases.
•   Código duplicado (hijos del copy/paste).
•   Largas listas de parámetros.
•   Mal uso de colecciones y estructuras de datos
    complejas
•   Abuso de la configuración del software.
•   Múltiples objetos con funcionalidades similares.
•   Exposición de implementaciones.
•   Código poco legible y/o poco mantenible.
•   Shotgun Surgery
Over-Engineering
• En estricto chileno… abusaste de tu creatividad.
• Uso excesivo de patrones cuando no es necesario.
• Aplicación a la fuerza de tecnologías.
• Nos olvidamos de mantener las cosas simples.
• Provoca lo mismo que un mal desarrollo, es decir, código
  difícil de entender y mantener.
• Extensas e inútiles jerarquías.
• No caer en “paranoia”.
Gráficamente Over-engineering
Facade
• Tipo: Estructural
• Nivel: Componente
• Propósito: proporcionar una interface simplificada para un grupo de
  subsistemas ó un sistema más complejo.
• Aplicabilidad: cuando se desee reducir el acoplamiento entre los clientes y
  los subsistemas. Otro uso es cuando se de desea introducir capas entre
  los subsistemas proporcionando fachadas para acceder a estos
  subsistemas.
• Descripción: la intención principal del patrón no es esconder los
  subsistemas, si no proporcionar más simple para un conjunto de
  subsistemas, permitiendo que los clientes más avanzados puedan utilizar
  las opciones más elaboradas y trabajen directamente con dichos
  subsistemas.
Implementación




Facade: la clase que utilizan los clientes. Conoce los subsistemas utilizados y sus respectivas
Responsabilidades. Normalmente, todas las peticiones de clientes serán delegadas en los
Subsistemas apropiados.

Módulo X: Conjuntos de clases que pueden ser utilizadas directamente por los clientes
ó hacer el trabajo asignado por el objeto Facade.
Ventajas e Inconvenientes

• Traduce las peticiones del cliente a los subsistemas
  que pueden cumplir esos llamados. La mayor parte de las
  veces, una petición será delegada en más de un sistema. Como el
  cliente sólo interactúa con el Facade, el funcionamiento interno
  puede ser modificado, mientras que el cliente del Facade puede
  permanecer igual.
Prototype
• Tipo: creación
• Nivel: clase única
• Propósito: Facilita la creación dinámica al definir clases cuyos objetos
  pueden crear copias de si mismos.
• Descripción: Simplemente proporciona un mecanismo para que haya un
  objeto utilizado como base para crear una instancia con los mismos
  valores. Como proporciona un comportamiento de “creación basada en un
  estado existente”, es posible que los programas lleven a cabo operaciones
  como la copia dirigida por el usuario, al tiempo que permite inicializar los
  objetos a un estado que ha sido establecido durante el uso del sistema.
• Aplicabilidad: Utilice el patrón cuando desee crear un objeto que sea una
  copia de un objeto existente.
Implementación




Prototype: declara la interface para realizar la clonación.
ConcretePrototype: Clase que implementa la clonación.
Client: Realiza la petición de copia del objeto.

Patrones Relacionados
• Abstract Factory: puede utilizar prototype para crear nuevos objetos
basandose en el uso actual de la fábrica.

•Factory Method: los métodos de fabricación pueden utilizar un Prototype
para actuar como plantilla para los nuevos objetos.
Memento
• Tipo: de comportamiento.
• Nivel: objeto
• Propósito: Guardar una “instancia” del estado de un objeto, de forma que
  pueda ser devuelto a su estado original sin revelar su contenido al resto
  del mundo.
• Descripción: Los objetos mantienen un estado internamente, el cual es
  accesado a través de métodos. Pero sería necesario pasar el estado actual
  a otro objeto, para que sea posible restaurar el estado del objeto en un
  momento posterior (deshacer). Para ello, se encapsula el estado que se
  quiere conservar, utilizando memento. Un memento es un objeto que
  contiene el estado interno actual del objeto Originirator. Solo el Originator
  puede almacenar y recuperar información de Memento.
Aplicabilidad
Usar el patrón cuando se den estas condiciones:

• Debe tomarse una instantánea del estado de un objeto.
• Dicha instantánea debe ser usada para restaurar el estado original.
•    Implementación




    • Originator: crea el memento y lo utiliza para recuperar su estado.
    • Memento: clase estática de Originator que contiene su estado. El originator
      determina qué datos almacenar en el Memento y solo el Originator debe ser capaz
      de leer el memento.
    • StateHolder: el objeto que desea preservar su estado. Nunca necesita saber qué
      hay en el memento; sólo necesita saber que el objeto que recibe permite restaurar
      el estado del originator.
Ventajas e Inconvenientes

• Deja alguna información en un objeto para que sea
  accesible por otro objeto utilizando control de acceso por defecto.
• Es conveniente de usar en transacciones a Bases de Datos
• Se recomienda su uso cuando se deban considerar operaciones undo/redo
• El Originator es más simple, en este patrón se da la responsabilidad de
  almacenar los distintos estados a la parte solicitante (el cliente).


Patrones Relacionados
• Command: utiliza mementos para registrar el estado de acciones que no
  se pueden deshacer.
• State: la mayoría de los estados utilizan el patrón memento.
Proxy
• Tipo: Estructural
• Nivel: componente
• Propósito: Proporcionar un representante de otro objeto, por
  distintas razones, como pueden ser el acceso, la velocidad,
  o la seguridad, entre otras.
• Descripción: Obliga a que las llamadas a un objeto ocurran
  indirectamente a través de un objeto proxy, que actúa como
  sustituto del original, delegando las llamadas a los métodos de los
  objetos respectivos.
Implementación




Subject: Define la interface común para el RealSubject y el proxy, de modo que pueda usarse
un proxy en cualquier sitio en el que se espere un RealSubject.

RealSubject: Define el objeto real representado.

Proxy: Mantiene una referencia que permite al proxy acceder al objeto real. Proporciona una
Interface idéntica a la del subject, de manera que pueda ser sustituido. Controla el acceso al
objeto real y puede ser responsable de su creación y borrado.
Patrones Relacionados
• HOOP (Half Object Plus Protocol): este patrón
  puede utilizar el proxy para establecer la comunicación
  entre las 2 partes distribuidas del HOPP.
• Business Delegate: este patrón puede ser utilizado como un
  proxy. El delegado de negocios puede ser un representante
  local de un nivel de negocios.
Model – View – Controller
• Tipo: comportamiento
• Nivel: componente – arquitectura
• Propósito: Divide un componente ó un subsistema en tres lógicas –
  modelo, vista y controlador – facilitando la modificación o personalización
  de cada parte.
• El modelo: es un conjunto de clases que representan la información del
  mundo real que el sistema debe procesar, desconoce la existencia de las
  vistas y del controlador. Ese enfoque suena interesante, pero en la práctica
  no es aplicable pues deben existir interfaces que permitan a los módulos
  comunicarse entre sí.
• Modelo del dominio: Se podría decir que el modelo del dominio (o el
  modelo propiamente dicho) es el conjunto de clases que un ingeniero de
  software modela al analizar el problema que desea resolver.
Model – View - Controller

  •   El modelo de la aplicación: es un conjunto de clases
      que se relacionan con el modelo del dominio,
      que tienen conocimiento de las vistas y que implementan los mecanismos
      necesarios para notificar a éstas últimas sobre los cambios que se pudieren
      dar en el modelo del dominio.

  •   Vistas: son el conjunto de componentes que se encargan de mostrar al usuario
      la información contenida en el modelo. Una vista está asociada a un modelo,
      pudiendo existir varias vistas asociadas al mismo modelo; así por ejemplo, se
      puede tener una vista mostrando la hora del sistema como un reloj analógico y
      otra vista mostrando la misma información como un reloj digital.

  •   El controlador : es un objeto que se encarga de dirigir el flujo del control de la
      aplicación debido a mensajes externos, como datos introducidos por el
      usuario u opciones del menú seleccionadas por él. A partir de estos mensajes,
      el controlador se encarga de modificar el modelo o de abrir y cerrar vistas. El
      controlador tiene acceso al modelo y a las vistas, pero las vistas y el modelo no
      conocen de la existencia del controlador
Implementación
Variaciones del patrón

• Modelo push frente al modelo pull: en MVC se puede implementar una ó
  más formas que el modelo envíe las actualizaciones a su vista (ó vistas) ó
  que una de ellas pueda recuperar información del modelo conforme la
  necesita. La elección afecta a cómo se implementan las relaciones del
  sistema.

• Múltiples objetivos vista: un modelo puede proporcionar información a
  más de una vista. Esto resulta particularmente útil en algunas
  implementaciones de interfaces gráficas, porque los mismos datos deben
  llevar algunas veces a distintas representaciones.

• Vistas “ver pero no tocar”: no todas las vistas necesitan un controlador.
  Algunas proporcionarán solo una representación visual de los datos del
  modelo, pero no soportan ningún cambio en el modelo de la vista.
Ventajas

• La aplicación se desarrolla en forma modular
• Las modificaciones en las vistas no afectan a los otros módulos.
• MVC es bastante utilizado en la actualidad en marcos de aplicación
  orientados a objeto desarrollados para construir aplicaciones de
  gran tamaño; Java Swing, Apache Struts, Microsoft ASP.NET, las
  transformaciones XSL o incluso los documentos LATEX siguen este
  patrón de diseño.
Anti patrones de Diseño
• Son “soluciones” negativas que presentan más
  problemas que los que solucionan.
• Son una extensión natural de los patrones de diseño.
• La idea es comprender los antipatrones para intentar evitarlos
  y/o recuperarse de ellos.
• Se documentan generalmente con cierto cinismo para
  hacerlos fáciles de recordar.
• Según James Coplien, un antipatrón es algo que se ve como
  una buena idea, pero que falla de pésima forma cuando se le
  implementa.
Ejemplos de Anti Patrones
•   Nombre antipatrón: The Blob (La mancha)
•   Nombre alternativo: Winnebago and the God class.
•   Afecta a: la aplicación completa.
•   Solución: Refactorización de responsabilidades.
•   Se produce por: flojera, estar contra el tiempo.
•   Problema que provoca: manejo de funcionalidades, rendimiento, complejidad.
•   Evidencia anecdótica: “Esta clase es realmente el corazón de la arquitectura”.
Consecuencias y síntomas
• Una sola clase con un gran número de atributos y operaciones.
• Una clase con 60 ó más atributos y operaciones claramente
   indica la presencia de un blob.
• Ausencia de orientación a objetos, se programa en forma estructurada
  como si tuviésemos un main.
• La clase Blob es usualmente complicada de reusar, mantener, testear, etc.
• Dicha clase es muy costosa de mantener en memoria, lo que repercute
  directamente en el rendimiento de la aplicación.

• Excepción: Es aceptable cuando hacemos un wrapper de un sistema
   legacy.

• Solución: Refactorizar y recomponer atributos y operaciones definiendo
   de mejor forma las resposabilidades de cada funcionalidad.
• Nombre antipatrón: Lava Flow (Flujo de Lava).
• Nombre alternativo: Dead Code.
• Afecta a: La aplicación completa.
• Solución: mecanismo de configuración de la arquitectura.
• Se produce por: flojera.
• Problema que provoca: escasa mantenibilidad del código, problemas de
  performance.
• Evidencia anecdótica: “ahh eso, ese es un código que escribió Juan y la
  verdad no se si se usa todavía pero por si acaso… mejor dejémoslo. No está
  documentada esa funcionalidad, dejémosla por ahora… en último de los
  casos la podríamos comentar”.
Consecuencias y síntomas
• Clases, atributos u operaciones absolutamente injustificables
  en el código.
• Código que, a pesar de no saber quién lo usa ni que función cumple, no
  podemos eliminarlo.
• Si el flujo de lava no es eliminado, con el tiempo sigue causando
  problemas al momento de la mantención, y nos llenamos de clases y
  código ínútil.

• Excepción: Es aceptable cuando estamos trabajando en función de un
   ambiente solo para generar prototipos y no requerirá mayor mantención
   en el tiempo.

• Solución: la arquitectura y el diseño de clases debe estar claramente
   definido, con sus funcionalidades claras, documentado, y cuando tenemos
   operaciones comunes a la aplicación, esta debe ser parte de componentes
   más genéricos o de arquitectura.
非常感謝您!
(Muchas gracias!)

Contenu connexe

Tendances

Mi lenguaje de programación de preferencia
Mi lenguaje de programación de preferenciaMi lenguaje de programación de preferencia
Mi lenguaje de programación de preferenciaglfloresgilberto
 
Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de softwareEsteban Espinel
 
Introducción a los patrones de diseño
Introducción a los patrones de diseñoIntroducción a los patrones de diseño
Introducción a los patrones de diseñoMario Solarte
 
Buenas prácticas para la construcción de software
Buenas prácticas para la construcción de softwareBuenas prácticas para la construcción de software
Buenas prácticas para la construcción de softwareIker Canarias
 
Topicos Avanzados de Programacion - Unidad 3 componentes y librerias
Topicos Avanzados de Programacion - Unidad 3 componentes y libreriasTopicos Avanzados de Programacion - Unidad 3 componentes y librerias
Topicos Avanzados de Programacion - Unidad 3 componentes y libreriasJosé Antonio Sandoval Acosta
 
Buider Patron de Diseño
Buider Patron de DiseñoBuider Patron de Diseño
Buider Patron de DiseñoMario Cabrera
 
Guis en java-1pp_2012_
Guis en java-1pp_2012_Guis en java-1pp_2012_
Guis en java-1pp_2012_Robert Wolf
 
Java - Tutorial Ventanas
Java - Tutorial VentanasJava - Tutorial Ventanas
Java - Tutorial Ventanaselsemieni
 
Java GUI La librería Swing
Java GUI La librería Swing Java GUI La librería Swing
Java GUI La librería Swing Laura
 
Patrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. JaramilloPatrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. Jaramillo2008PA2Info3
 
Diapositivas sobre AWT
Diapositivas sobre AWTDiapositivas sobre AWT
Diapositivas sobre AWTLaddy Mathita
 
Introducción a Swing
Introducción a SwingIntroducción a Swing
Introducción a Swingmrojas_unitec
 
Subversion - buenas prácticas
Subversion - buenas prácticasSubversion - buenas prácticas
Subversion - buenas prácticasIker Canarias
 

Tendances (17)

Mi lenguaje de programación de preferencia
Mi lenguaje de programación de preferenciaMi lenguaje de programación de preferencia
Mi lenguaje de programación de preferencia
 
Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de software
 
Introducción a los patrones de diseño
Introducción a los patrones de diseñoIntroducción a los patrones de diseño
Introducción a los patrones de diseño
 
Buenas prácticas para la construcción de software
Buenas prácticas para la construcción de softwareBuenas prácticas para la construcción de software
Buenas prácticas para la construcción de software
 
Topicos Avanzados de Programacion - Unidad 3 componentes y librerias
Topicos Avanzados de Programacion - Unidad 3 componentes y libreriasTopicos Avanzados de Programacion - Unidad 3 componentes y librerias
Topicos Avanzados de Programacion - Unidad 3 componentes y librerias
 
Buider Patron de Diseño
Buider Patron de DiseñoBuider Patron de Diseño
Buider Patron de Diseño
 
Guis en java-1pp_2012_
Guis en java-1pp_2012_Guis en java-1pp_2012_
Guis en java-1pp_2012_
 
Java - Tutorial Ventanas
Java - Tutorial VentanasJava - Tutorial Ventanas
Java - Tutorial Ventanas
 
Java GUI La librería Swing
Java GUI La librería Swing Java GUI La librería Swing
Java GUI La librería Swing
 
Patrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. JaramilloPatrones de diseño - Daniel E. Jaramillo
Patrones de diseño - Daniel E. Jaramillo
 
Sesion12-componentes Visuales java
Sesion12-componentes Visuales javaSesion12-componentes Visuales java
Sesion12-componentes Visuales java
 
Diapositivas sobre AWT
Diapositivas sobre AWTDiapositivas sobre AWT
Diapositivas sobre AWT
 
Abstract Factory
Abstract FactoryAbstract Factory
Abstract Factory
 
Introducción a Swing
Introducción a SwingIntroducción a Swing
Introducción a Swing
 
Subversion - buenas prácticas
Subversion - buenas prácticasSubversion - buenas prácticas
Subversion - buenas prácticas
 
Diferencias swing y awt
Diferencias swing y awtDiferencias swing y awt
Diferencias swing y awt
 
Jfc java
Jfc javaJfc java
Jfc java
 

En vedette

Cadena de responsabilidad.chaine of responsability
Cadena de responsabilidad.chaine of responsabilityCadena de responsabilidad.chaine of responsability
Cadena de responsabilidad.chaine of responsabilityUTCH
 
Patrones de diseño de software facade e iterator
Patrones de diseño de software facade e iteratorPatrones de diseño de software facade e iterator
Patrones de diseño de software facade e iteratorPietro Doninelli
 
Facade - Design Pattern - GoF
Facade - Design Pattern - GoFFacade - Design Pattern - GoF
Facade - Design Pattern - GoFjlrvpuma
 
Ccna3 cap8 (1)
Ccna3 cap8 (1)Ccna3 cap8 (1)
Ccna3 cap8 (1)José Mora
 
Architecture in agile projects
Architecture in agile projectsArchitecture in agile projects
Architecture in agile projectsLeonardo Rosales
 
Patrones de diseño II
Patrones de diseño IIPatrones de diseño II
Patrones de diseño IIjjegonzalezf
 
Análisis de arquitecturas de software
Análisis de arquitecturas de softwareAnálisis de arquitecturas de software
Análisis de arquitecturas de softwareJorge Rodriguez
 
Patron Memento
Patron MementoPatron Memento
Patron MementoAn3s
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspJuan Pablo Bustos Thames
 
Diseño de Patrones (Fachada)
Diseño de Patrones (Fachada)Diseño de Patrones (Fachada)
Diseño de Patrones (Fachada)Fanny Ruiz
 
Patrones bridge puente
Patrones bridge puentePatrones bridge puente
Patrones bridge puenteMario Cabrera
 
1.1ARQUITECTURA DE CUATRO MAS UN VISTAS
1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS
1.1ARQUITECTURA DE CUATRO MAS UN VISTASadolfo0890
 
El diagrama en la arquitectura.
El diagrama en la arquitectura.El diagrama en la arquitectura.
El diagrama en la arquitectura.Luis Xhaparro
 
Why We Need Architects (and Architecture) on Agile Projects
Why We Need Architects (and Architecture) on Agile ProjectsWhy We Need Architects (and Architecture) on Agile Projects
Why We Need Architects (and Architecture) on Agile ProjectsRebecca Wirfs-Brock
 
2 1 vistas arquitectonicas
2 1 vistas arquitectonicas2 1 vistas arquitectonicas
2 1 vistas arquitectonicaslandeta_p
 
Especificación de Arquitectura de Software
Especificación de Arquitectura de SoftwareEspecificación de Arquitectura de Software
Especificación de Arquitectura de SoftwareSoftware Guru
 
Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Marta Silvia Tabares
 
Arquitectura De Software Para Dummies
Arquitectura De Software Para DummiesArquitectura De Software Para Dummies
Arquitectura De Software Para DummiesSorey García
 
Chapter 5 software design
Chapter 5 software designChapter 5 software design
Chapter 5 software designPiyush Gogia
 

En vedette (20)

Cadena de responsabilidad.chaine of responsability
Cadena de responsabilidad.chaine of responsabilityCadena de responsabilidad.chaine of responsability
Cadena de responsabilidad.chaine of responsability
 
Patrones de diseño de software facade e iterator
Patrones de diseño de software facade e iteratorPatrones de diseño de software facade e iterator
Patrones de diseño de software facade e iterator
 
Facade - Design Pattern - GoF
Facade - Design Pattern - GoFFacade - Design Pattern - GoF
Facade - Design Pattern - GoF
 
Ccna3 cap8 (1)
Ccna3 cap8 (1)Ccna3 cap8 (1)
Ccna3 cap8 (1)
 
Decorator
DecoratorDecorator
Decorator
 
Architecture in agile projects
Architecture in agile projectsArchitecture in agile projects
Architecture in agile projects
 
Patrones de diseño II
Patrones de diseño IIPatrones de diseño II
Patrones de diseño II
 
Análisis de arquitecturas de software
Análisis de arquitecturas de softwareAnálisis de arquitecturas de software
Análisis de arquitecturas de software
 
Patron Memento
Patron MementoPatron Memento
Patron Memento
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. grasp
 
Diseño de Patrones (Fachada)
Diseño de Patrones (Fachada)Diseño de Patrones (Fachada)
Diseño de Patrones (Fachada)
 
Patrones bridge puente
Patrones bridge puentePatrones bridge puente
Patrones bridge puente
 
1.1ARQUITECTURA DE CUATRO MAS UN VISTAS
1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS
1.1ARQUITECTURA DE CUATRO MAS UN VISTAS
 
El diagrama en la arquitectura.
El diagrama en la arquitectura.El diagrama en la arquitectura.
El diagrama en la arquitectura.
 
Why We Need Architects (and Architecture) on Agile Projects
Why We Need Architects (and Architecture) on Agile ProjectsWhy We Need Architects (and Architecture) on Agile Projects
Why We Need Architects (and Architecture) on Agile Projects
 
2 1 vistas arquitectonicas
2 1 vistas arquitectonicas2 1 vistas arquitectonicas
2 1 vistas arquitectonicas
 
Especificación de Arquitectura de Software
Especificación de Arquitectura de SoftwareEspecificación de Arquitectura de Software
Especificación de Arquitectura de Software
 
Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1
 
Arquitectura De Software Para Dummies
Arquitectura De Software Para DummiesArquitectura De Software Para Dummies
Arquitectura De Software Para Dummies
 
Chapter 5 software design
Chapter 5 software designChapter 5 software design
Chapter 5 software design
 

Similaire à Patrones de diseño II

Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de softwareIker Canarias
 
Patrones de diseño - Andrés Dorado
Patrones de diseño - Andrés DoradoPatrones de diseño - Andrés Dorado
Patrones de diseño - Andrés Dorado2008PA2Info3
 
Patrones de Diseño de Software
Patrones de Diseño de SoftwarePatrones de Diseño de Software
Patrones de Diseño de SoftwareWilliam A. Molina
 
Desarrollo basado en patrones
Desarrollo basado en patronesDesarrollo basado en patrones
Desarrollo basado en patronesMarvin Zumbado
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño Ijjegonzalezf
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiRaimonKoudsi
 
Msdn Webcast InyeccióN De Dependencias Con Spring Framework
Msdn Webcast   InyeccióN De Dependencias Con Spring FrameworkMsdn Webcast   InyeccióN De Dependencias Con Spring Framework
Msdn Webcast InyeccióN De Dependencias Con Spring FrameworkGabriel Oliva
 
Resumen para Estudiar
Resumen para EstudiarResumen para Estudiar
Resumen para Estudiargregoryj733
 
Patrones estructurados
Patrones estructuradosPatrones estructurados
Patrones estructuradosIsmael Armijos
 
Catalogo de patrones 0
Catalogo de patrones 0Catalogo de patrones 0
Catalogo de patrones 0Fabio Ruiz
 
02 -introduccion_a_la_tecnologia_orientada_a_objetos
02  -introduccion_a_la_tecnologia_orientada_a_objetos02  -introduccion_a_la_tecnologia_orientada_a_objetos
02 -introduccion_a_la_tecnologia_orientada_a_objetoskarlalopezbello
 
Prototipado rapido de interfaces
Prototipado rapido de interfacesPrototipado rapido de interfaces
Prototipado rapido de interfacesGaby Fernandez
 
Probando aplicaciones AngularJS
Probando aplicaciones AngularJSProbando aplicaciones AngularJS
Probando aplicaciones AngularJSRodrigo Pimentel
 
Introducción a Android
Introducción a AndroidIntroducción a Android
Introducción a Androidmcanalesc94
 

Similaire à Patrones de diseño II (20)

Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de software
 
Introducción a DDD
Introducción a DDDIntroducción a DDD
Introducción a DDD
 
6070_TRECALDE_00288.ppt
6070_TRECALDE_00288.ppt6070_TRECALDE_00288.ppt
6070_TRECALDE_00288.ppt
 
Patrones de diseño - Andrés Dorado
Patrones de diseño - Andrés DoradoPatrones de diseño - Andrés Dorado
Patrones de diseño - Andrés Dorado
 
Patrones de Diseño de Software
Patrones de Diseño de SoftwarePatrones de Diseño de Software
Patrones de Diseño de Software
 
Desarrollo basado en patrones
Desarrollo basado en patronesDesarrollo basado en patrones
Desarrollo basado en patrones
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño I
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
 
Msdn Webcast InyeccióN De Dependencias Con Spring Framework
Msdn Webcast   InyeccióN De Dependencias Con Spring FrameworkMsdn Webcast   InyeccióN De Dependencias Con Spring Framework
Msdn Webcast InyeccióN De Dependencias Con Spring Framework
 
Resumen para Estudiar
Resumen para EstudiarResumen para Estudiar
Resumen para Estudiar
 
Patrones estructurados
Patrones estructuradosPatrones estructurados
Patrones estructurados
 
Framework
FrameworkFramework
Framework
 
Catalogo de patrones 0
Catalogo de patrones 0Catalogo de patrones 0
Catalogo de patrones 0
 
Cliente/Servidor
Cliente/ServidorCliente/Servidor
Cliente/Servidor
 
02 -introduccion_a_la_tecnologia_orientada_a_objetos
02  -introduccion_a_la_tecnologia_orientada_a_objetos02  -introduccion_a_la_tecnologia_orientada_a_objetos
02 -introduccion_a_la_tecnologia_orientada_a_objetos
 
Prototipado rapido de interfaces
Prototipado rapido de interfacesPrototipado rapido de interfaces
Prototipado rapido de interfaces
 
Probando aplicaciones AngularJS
Probando aplicaciones AngularJSProbando aplicaciones AngularJS
Probando aplicaciones AngularJS
 
Introducción a Android
Introducción a AndroidIntroducción a Android
Introducción a Android
 
1127082.ppt
1127082.ppt1127082.ppt
1127082.ppt
 
Sistemas distribuidos
Sistemas distribuidosSistemas distribuidos
Sistemas distribuidos
 

Plus de kaolong

Ic301 getting started
Ic301 getting startedIc301 getting started
Ic301 getting startedkaolong
 
Junit y Jmock
Junit y JmockJunit y Jmock
Junit y Jmockkaolong
 
Consejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usoConsejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usokaolong
 
Estandar programacion plsql
Estandar programacion plsqlEstandar programacion plsql
Estandar programacion plsqlkaolong
 
Norma de programacion plsql
Norma de programacion plsqlNorma de programacion plsql
Norma de programacion plsqlkaolong
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño Ikaolong
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño Ikaolong
 
Charla Jquery
Charla JqueryCharla Jquery
Charla Jquerykaolong
 
charla SOA
charla SOAcharla SOA
charla SOAkaolong
 
FMK Capa de Presentacion
FMK Capa de PresentacionFMK Capa de Presentacion
FMK Capa de Presentacionkaolong
 
Charla Ejbs
Charla EjbsCharla Ejbs
Charla Ejbskaolong
 

Plus de kaolong (16)

Ic301 getting started
Ic301 getting startedIc301 getting started
Ic301 getting started
 
Junit y Jmock
Junit y JmockJunit y Jmock
Junit y Jmock
 
Consejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usoConsejos para escribir buenos casos de uso
Consejos para escribir buenos casos de uso
 
Estandar programacion plsql
Estandar programacion plsqlEstandar programacion plsql
Estandar programacion plsql
 
Norma de programacion plsql
Norma de programacion plsqlNorma de programacion plsql
Norma de programacion plsql
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño I
 
Patrones de diseño I
Patrones de diseño IPatrones de diseño I
Patrones de diseño I
 
Charla Jquery
Charla JqueryCharla Jquery
Charla Jquery
 
charla SOA
charla SOAcharla SOA
charla SOA
 
FMK Capa de Presentacion
FMK Capa de PresentacionFMK Capa de Presentacion
FMK Capa de Presentacion
 
Charla Ejbs
Charla EjbsCharla Ejbs
Charla Ejbs
 
Uml
UmlUml
Uml
 
Jsf
JsfJsf
Jsf
 
Jcc
JccJcc
Jcc
 
Poo
PooPoo
Poo
 
Jcc
JccJcc
Jcc
 

Patrones de diseño II

  • 1. Patrones de Diseño II “Si la depuración es el proceso de buscar y eliminar errores, entonces la programación debe ser el proceso de introducirlos.” Esdger Dijkstra. “Con el software el software en producción, la corrección de errores es como reparar un auto mientras está siendo conducido por la carretera.” Imagemaker IT Agosto, 2011
  • 2. Temario • Reutilización • Refactorización • Cuando aplicarla – Bad Smells • Over-Engineering • Facade • Prototype • Memento • Proxy • Model – View – Controller • Antipatrones • Ejemplos
  • 3. Reutilización Históricamente se ha buscado la reutilización en el desarrollo de software
  • 4. Refactorización • Es el cambio en un sistema software de tal forma que no se altere su comportamiento externo (no se añade funcionalidad) si no que mejora su estructura interna. • Es una manera disciplinada de “limpiar” el código que minimiza el riesgo de introducir bugs. • Cuando se refactoriza, se mejora el diseño que se ha escrito permitiendo que sea más fácil de comprender y cambiar. • Esta se realiza a menudo como parte del proceso de desarrollo de SW. • Se debe alternar el desarrollo de nuevas funcionalidades y casos de uso (tests) para garantizar que las mejoras no han alterado el comportamiento del sistema.
  • 5. Cuando aplicarla – Bad Smells • Muchas líneas de código en las clases. • Código duplicado (hijos del copy/paste). • Largas listas de parámetros. • Mal uso de colecciones y estructuras de datos complejas • Abuso de la configuración del software. • Múltiples objetos con funcionalidades similares. • Exposición de implementaciones. • Código poco legible y/o poco mantenible. • Shotgun Surgery
  • 6. Over-Engineering • En estricto chileno… abusaste de tu creatividad. • Uso excesivo de patrones cuando no es necesario. • Aplicación a la fuerza de tecnologías. • Nos olvidamos de mantener las cosas simples. • Provoca lo mismo que un mal desarrollo, es decir, código difícil de entender y mantener. • Extensas e inútiles jerarquías. • No caer en “paranoia”.
  • 8. Facade • Tipo: Estructural • Nivel: Componente • Propósito: proporcionar una interface simplificada para un grupo de subsistemas ó un sistema más complejo. • Aplicabilidad: cuando se desee reducir el acoplamiento entre los clientes y los subsistemas. Otro uso es cuando se de desea introducir capas entre los subsistemas proporcionando fachadas para acceder a estos subsistemas. • Descripción: la intención principal del patrón no es esconder los subsistemas, si no proporcionar más simple para un conjunto de subsistemas, permitiendo que los clientes más avanzados puedan utilizar las opciones más elaboradas y trabajen directamente con dichos subsistemas.
  • 9. Implementación Facade: la clase que utilizan los clientes. Conoce los subsistemas utilizados y sus respectivas Responsabilidades. Normalmente, todas las peticiones de clientes serán delegadas en los Subsistemas apropiados. Módulo X: Conjuntos de clases que pueden ser utilizadas directamente por los clientes ó hacer el trabajo asignado por el objeto Facade.
  • 10. Ventajas e Inconvenientes • Traduce las peticiones del cliente a los subsistemas que pueden cumplir esos llamados. La mayor parte de las veces, una petición será delegada en más de un sistema. Como el cliente sólo interactúa con el Facade, el funcionamiento interno puede ser modificado, mientras que el cliente del Facade puede permanecer igual.
  • 11. Prototype • Tipo: creación • Nivel: clase única • Propósito: Facilita la creación dinámica al definir clases cuyos objetos pueden crear copias de si mismos. • Descripción: Simplemente proporciona un mecanismo para que haya un objeto utilizado como base para crear una instancia con los mismos valores. Como proporciona un comportamiento de “creación basada en un estado existente”, es posible que los programas lleven a cabo operaciones como la copia dirigida por el usuario, al tiempo que permite inicializar los objetos a un estado que ha sido establecido durante el uso del sistema. • Aplicabilidad: Utilice el patrón cuando desee crear un objeto que sea una copia de un objeto existente.
  • 12. Implementación Prototype: declara la interface para realizar la clonación. ConcretePrototype: Clase que implementa la clonación. Client: Realiza la petición de copia del objeto. Patrones Relacionados • Abstract Factory: puede utilizar prototype para crear nuevos objetos basandose en el uso actual de la fábrica. •Factory Method: los métodos de fabricación pueden utilizar un Prototype para actuar como plantilla para los nuevos objetos.
  • 13. Memento • Tipo: de comportamiento. • Nivel: objeto • Propósito: Guardar una “instancia” del estado de un objeto, de forma que pueda ser devuelto a su estado original sin revelar su contenido al resto del mundo. • Descripción: Los objetos mantienen un estado internamente, el cual es accesado a través de métodos. Pero sería necesario pasar el estado actual a otro objeto, para que sea posible restaurar el estado del objeto en un momento posterior (deshacer). Para ello, se encapsula el estado que se quiere conservar, utilizando memento. Un memento es un objeto que contiene el estado interno actual del objeto Originirator. Solo el Originator puede almacenar y recuperar información de Memento.
  • 14. Aplicabilidad Usar el patrón cuando se den estas condiciones: • Debe tomarse una instantánea del estado de un objeto. • Dicha instantánea debe ser usada para restaurar el estado original.
  • 15. Implementación • Originator: crea el memento y lo utiliza para recuperar su estado. • Memento: clase estática de Originator que contiene su estado. El originator determina qué datos almacenar en el Memento y solo el Originator debe ser capaz de leer el memento. • StateHolder: el objeto que desea preservar su estado. Nunca necesita saber qué hay en el memento; sólo necesita saber que el objeto que recibe permite restaurar el estado del originator.
  • 16. Ventajas e Inconvenientes • Deja alguna información en un objeto para que sea accesible por otro objeto utilizando control de acceso por defecto. • Es conveniente de usar en transacciones a Bases de Datos • Se recomienda su uso cuando se deban considerar operaciones undo/redo • El Originator es más simple, en este patrón se da la responsabilidad de almacenar los distintos estados a la parte solicitante (el cliente). Patrones Relacionados • Command: utiliza mementos para registrar el estado de acciones que no se pueden deshacer. • State: la mayoría de los estados utilizan el patrón memento.
  • 17. Proxy • Tipo: Estructural • Nivel: componente • Propósito: Proporcionar un representante de otro objeto, por distintas razones, como pueden ser el acceso, la velocidad, o la seguridad, entre otras. • Descripción: Obliga a que las llamadas a un objeto ocurran indirectamente a través de un objeto proxy, que actúa como sustituto del original, delegando las llamadas a los métodos de los objetos respectivos.
  • 18. Implementación Subject: Define la interface común para el RealSubject y el proxy, de modo que pueda usarse un proxy en cualquier sitio en el que se espere un RealSubject. RealSubject: Define el objeto real representado. Proxy: Mantiene una referencia que permite al proxy acceder al objeto real. Proporciona una Interface idéntica a la del subject, de manera que pueda ser sustituido. Controla el acceso al objeto real y puede ser responsable de su creación y borrado.
  • 19. Patrones Relacionados • HOOP (Half Object Plus Protocol): este patrón puede utilizar el proxy para establecer la comunicación entre las 2 partes distribuidas del HOPP. • Business Delegate: este patrón puede ser utilizado como un proxy. El delegado de negocios puede ser un representante local de un nivel de negocios.
  • 20. Model – View – Controller • Tipo: comportamiento • Nivel: componente – arquitectura • Propósito: Divide un componente ó un subsistema en tres lógicas – modelo, vista y controlador – facilitando la modificación o personalización de cada parte. • El modelo: es un conjunto de clases que representan la información del mundo real que el sistema debe procesar, desconoce la existencia de las vistas y del controlador. Ese enfoque suena interesante, pero en la práctica no es aplicable pues deben existir interfaces que permitan a los módulos comunicarse entre sí. • Modelo del dominio: Se podría decir que el modelo del dominio (o el modelo propiamente dicho) es el conjunto de clases que un ingeniero de software modela al analizar el problema que desea resolver.
  • 21. Model – View - Controller • El modelo de la aplicación: es un conjunto de clases que se relacionan con el modelo del dominio, que tienen conocimiento de las vistas y que implementan los mecanismos necesarios para notificar a éstas últimas sobre los cambios que se pudieren dar en el modelo del dominio. • Vistas: son el conjunto de componentes que se encargan de mostrar al usuario la información contenida en el modelo. Una vista está asociada a un modelo, pudiendo existir varias vistas asociadas al mismo modelo; así por ejemplo, se puede tener una vista mostrando la hora del sistema como un reloj analógico y otra vista mostrando la misma información como un reloj digital. • El controlador : es un objeto que se encarga de dirigir el flujo del control de la aplicación debido a mensajes externos, como datos introducidos por el usuario u opciones del menú seleccionadas por él. A partir de estos mensajes, el controlador se encarga de modificar el modelo o de abrir y cerrar vistas. El controlador tiene acceso al modelo y a las vistas, pero las vistas y el modelo no conocen de la existencia del controlador
  • 23. Variaciones del patrón • Modelo push frente al modelo pull: en MVC se puede implementar una ó más formas que el modelo envíe las actualizaciones a su vista (ó vistas) ó que una de ellas pueda recuperar información del modelo conforme la necesita. La elección afecta a cómo se implementan las relaciones del sistema. • Múltiples objetivos vista: un modelo puede proporcionar información a más de una vista. Esto resulta particularmente útil en algunas implementaciones de interfaces gráficas, porque los mismos datos deben llevar algunas veces a distintas representaciones. • Vistas “ver pero no tocar”: no todas las vistas necesitan un controlador. Algunas proporcionarán solo una representación visual de los datos del modelo, pero no soportan ningún cambio en el modelo de la vista.
  • 24. Ventajas • La aplicación se desarrolla en forma modular • Las modificaciones en las vistas no afectan a los otros módulos. • MVC es bastante utilizado en la actualidad en marcos de aplicación orientados a objeto desarrollados para construir aplicaciones de gran tamaño; Java Swing, Apache Struts, Microsoft ASP.NET, las transformaciones XSL o incluso los documentos LATEX siguen este patrón de diseño.
  • 25. Anti patrones de Diseño • Son “soluciones” negativas que presentan más problemas que los que solucionan. • Son una extensión natural de los patrones de diseño. • La idea es comprender los antipatrones para intentar evitarlos y/o recuperarse de ellos. • Se documentan generalmente con cierto cinismo para hacerlos fáciles de recordar. • Según James Coplien, un antipatrón es algo que se ve como una buena idea, pero que falla de pésima forma cuando se le implementa.
  • 26. Ejemplos de Anti Patrones • Nombre antipatrón: The Blob (La mancha) • Nombre alternativo: Winnebago and the God class. • Afecta a: la aplicación completa. • Solución: Refactorización de responsabilidades. • Se produce por: flojera, estar contra el tiempo. • Problema que provoca: manejo de funcionalidades, rendimiento, complejidad. • Evidencia anecdótica: “Esta clase es realmente el corazón de la arquitectura”.
  • 27. Consecuencias y síntomas • Una sola clase con un gran número de atributos y operaciones. • Una clase con 60 ó más atributos y operaciones claramente indica la presencia de un blob. • Ausencia de orientación a objetos, se programa en forma estructurada como si tuviésemos un main. • La clase Blob es usualmente complicada de reusar, mantener, testear, etc. • Dicha clase es muy costosa de mantener en memoria, lo que repercute directamente en el rendimiento de la aplicación. • Excepción: Es aceptable cuando hacemos un wrapper de un sistema legacy. • Solución: Refactorizar y recomponer atributos y operaciones definiendo de mejor forma las resposabilidades de cada funcionalidad.
  • 28. • Nombre antipatrón: Lava Flow (Flujo de Lava). • Nombre alternativo: Dead Code. • Afecta a: La aplicación completa. • Solución: mecanismo de configuración de la arquitectura. • Se produce por: flojera. • Problema que provoca: escasa mantenibilidad del código, problemas de performance. • Evidencia anecdótica: “ahh eso, ese es un código que escribió Juan y la verdad no se si se usa todavía pero por si acaso… mejor dejémoslo. No está documentada esa funcionalidad, dejémosla por ahora… en último de los casos la podríamos comentar”.
  • 29. Consecuencias y síntomas • Clases, atributos u operaciones absolutamente injustificables en el código. • Código que, a pesar de no saber quién lo usa ni que función cumple, no podemos eliminarlo. • Si el flujo de lava no es eliminado, con el tiempo sigue causando problemas al momento de la mantención, y nos llenamos de clases y código ínútil. • Excepción: Es aceptable cuando estamos trabajando en función de un ambiente solo para generar prototipos y no requerirá mayor mantención en el tiempo. • Solución: la arquitectura y el diseño de clases debe estar claramente definido, con sus funcionalidades claras, documentado, y cuando tenemos operaciones comunes a la aplicación, esta debe ser parte de componentes más genéricos o de arquitectura.