clase 4 - programación iv - bsi1100

ESCUELA DE INGENIERÍA DE SISTEMAS INFORMÁTICOS

UNIVERSIDAD LATINALIC. RANDY VALVERDE VALVERDE

1

Programación IV

Desde el principio:

El término patrón fue utilizado por primera vez por el arquitecto Christopher Alexander en el libro “A Pattern Language: Towns, Buildings, Construction“, donde definió una serie de patrones arquitectónicos. Alexander define:

“Un patrón describe un problema que ocurre a menudo, acompañado por un intento de solución para el problema.”

Christopher Alexander, 1977

Randy V² - II Q – 2016, 100 % positivo

Desde el principio:

En 1987, Ward Cunningham y Kent Beck estaban trabajando con Smaltalk, diseñando interfaces de usuario. Para ello, decidieron utilizar alguna de las ideas de Alexander y desarrollaron un pequeño lenguaje de patrones que serviría de guía a los programadores de Smaltalk. A partir de estas idea escribieron el libro “Using Pattern Languajes for Object-Oriented Programs”.

Desde 1990 a 1994, Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (Gang of four) realizaron un primer catálogo de patrones de diseño. En 1994 publicarón el libro “Design Patterns – Elements of Reusable Object-Oriented Software“ que introducía el termino de patrón de diseño en el desarrollo del software.


¿Qué es un patrón de diseño? ¿Por qué usarlos? Categorización Problema - Patrón


5

Patrones

En las distintas actividades de la vida diaria se reconocen patrones: Trabajo Vida familiar Hobbies


Hardware


Hardware Software

Poder rehusar componentes y lograr un mantenimiento fácil.Lograr un software flexible

habitualmente


¿Qué es un patrón de diseño?

“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).

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.



CARACTERISTICAS:Ante un problema reiterado ofrece una

solución contrastada que lo resuelve.Describe el problema en forma sencilla.Describe el contexto en que ocurre.Describe los pasos a seguir.Describe los puntos fuertes y débiles de la

solución.Describe otros patrones asociados.



CARACTERISTICAS:Se definen con un alto nivel de abstracción.Son independientes de los lenguajes de

programación y de los detalles de implementación.

Los patrones promueven y facilitan la reutilización de arquitecturas y diseños de software que han demostrado su validez en muchas aplicaciones.


Patrones en la Ingeniería de Software

Pueden verse como bloques de construcción mentales, para tratar con distintos aspectos del diseño de software.

Hay patrones de arquitectura, patrones de diseño, patrones de procesos, patrones de interfaces, “idioms”.

No existen paradigmas o lenguajes específicos para implementar patrones de arquitectura, pero algunos proveen elementos útiles (orientación a objetos, polimorfismo, herencia, etc.).


¿Cómo se especifica un patrón?

Patrón: Nombre del PatrónContexto

Situación de diseño que da lugar al problema.

Problema

Conjunto de fuerzas que surgen del contexto.

Solución

Configuración para balancear las fuerzas

Componentes y relaciones (estructura)

Comportamiento dinámico


Contexto

Extiende la dicotomía problema-solución.Describe el escenario donde se da el problema.La descripción del contexto puede ser bastante

general o muy específica. Por ejemplo: “desarrollar software con una interfaz humano-

computador”. “implementar el mecanismo de cambio-propagación

en MVC”.Es muy difícil definir completamente el

contexto.Listar todas las situaciones en que el problema

surge puede ser una alternativa.Randy V² - II Q – 2016, 100 % positivo

Problema

Describe el problema genérico que surge en el contexto especificado.

Esencia: ¿cuál aspecto del problema debemos resolver? El problema generalmente varía, pero la

escencia se mantiene.Las fuerzas describen aspectos más

específicos del problema con distintos puntos de vista, y hasta pueden contradecirse. Pueden ser: requisitos de la solución restricciones propiedades deseables/indeseables


SoluciónEs la forma de balancear las fuerzas para

resolver el problema.Dos aspectos o componentes de la solución:

Estructura estática - componentes y relaciones. Comportamiento dinámico - forma de organización

y colaboración entre las componentes. La solución no siempre toma en cuenta todas

las fuerzas. Hay que establecer prioridades, si las fuerzas

son contradictorias.Se debe establecer un esquema de soluciones

y no algo completamente definido (demasiado especificado, y por ende, restrictivo).


Relación entre Patrones

“Cada patrón depende de los patrones más pequeños que contiene y de los más grandes donde está contenido.”

Distintos aspectos de un sistema pueden resolverse con distintos patrones.

Existen variantes de ciertos patrones para situaciones especiales.


Descripción de Patrones

Una descripción apropiada permite la comprensión, el análisis y la discusión del patrón.

La definición del Contexto-Problema-Solución es un buen punto de partida.

Los buenos nombres se convierten en jerga o modismos.

Ejemplos, diagramas, escenarios y guías para la implementación también pueden formar parte de la definición de un patrón.

Discusión de beneficios y debilidades ayudan a tomar mejores decisión respecto a su uso.


Descripción Completa de un Patrón

Ejemplo Ejemplo conocido de la literatura

Nombre Nombre descriptivo Contexto Situación en que surge el problema Problema Fuerzas que surgen en el contexto Solución Configuración que balancea las fuerzas Estructura Diagramas que describen la configuración Dinámica Descripción del comportamiento. Escenarios Implementación Guía para implementar el patrón Resolución del ejemplo

Aplicación del patrón al ejemplo

Variantes Alternativas para resolver el ejemplo Usos conocidos Descripción de problemas donde se aplica Consecuencias Beneficios y perjuicios


19

Arquitectura

1. Define la forma y la estructura de la aplicación de software.

2. Relacionada al propósito de la aplicación.

3. Arquitectura de módulos y sus interconexiones

Patrones de diseñoPaquetes, componentes, clases


20

Evidencias de diseño erróneo

Rigidez: problemas para insertar algún cambio.

Fragilidad: el software falla en muchos lugares al insertar un cambio.

Inmovilidad: no se pueden rehusar partes del proyecto.

Viscosidad: • De diseño: cuando se deben hacer cambios,

es más fácil hacer cosas mal, que bien.• De entorno: entorno de desarrollo ineficiente


¿Por qué usarlos?

Mejora en la comunicación y documentación “Hay que hacer un Factory Method” Facilita la documentación interna del proyecto.

Mejora la ingeniería de software. Eleva el nivel del grupo de desarrollo.

Previene “reinventar la rueda” en diseño Son soluciones ya probadas.

Mejora la calidad y estructura “¿Cuan grande debe ser una clase?”


Clasificación de patrones (GoF)

Patrones de creación: Tratan de la inicialización y configuración de clases y objetos.

Patrones estructurales: Tratan de desacoplar interfaz e implementación de clases y objetos.

Patrones de comportamiento: Tratan de las interacciones dinámicas entre sociedades de clases y objetos


Patrones de creación

The Factory Method retorna una de las posibles subclases de una clase abstracta dependiendo de los datos que se le provee.

The Abstract Factory Method retorna una de las varias familias de objetos.

The Builder Pattern separa la construcción de un objeto complejo de su representación. Varias representaciones se pueden crear dependiendo de las necesidades del programa.

The Prototype Pattern inicializa e instancia una clase y luego copia o clona si necesita otras instancias, mas que crear nuevas instancias.

The Singleton Pattern es una clase de la cual no puede existir mas de una instancia.


24

Patrones estructurales

Adapter: cambia la interfaz de una clase a la de otra.Bridge: permite mantener constante la interfaz que se

presenta al cliente, cambiando la clase que se usa Composite: una colección de objetosDecorator: una clase que envuelve a una clase dándole

nuevas capacidades.Facade: reúne una jerarquía compleja de objetos y provee

una clase nueva permitiendo acceder a cualquiera de las clases de la jerarquía.

Flyweight: permite limitar la proliferación de pequeñas clases similares.


25

Patrones de comportamiento

Cadena de responsabilidad: permite que un conjunto de clases intenten manejar un requerimiento.

Interpreter: define una gramática de un lenguaje y usa esa gramática para interpretar sentencias del lenguaje.

Iterator: permite recorrer una estructura de datos sin conocer detalles de cómo están implementados los datos

Observer: algunos objetos reflejan un cambio a raíz del cambio de otro, por lo tanto se le debe comunicar el cambio de este último.

Strategy: cantidad de algoritmos relacionados encerrados en un contexto a través del cual se selecciona uno de los algoritmos.


Otros tipos de patrones

Patrones de programación concurrentePatrones de interfaz gráficaPatrones de organización de códigoPatrones de optimización de códigoPatrones de robustez de códigoPatrones de fases de prueba


Beneficios de los patrones

Los patrones favorecen la reutilización de diseños y arquitecturas a gran escala.

Capturan el conocimiento de los expertos y lo hacen accesible a toda la comunidad software.

Proporcionan un cuerpo de conocimiento utilizable por toda la comunidad software.

Favorecen la transmisión de conocimiento entre profesionales y entre clientes y desarrolladores

Proporcionan un lenguaje común. Los nombres de los patrones forman parte del vocabulario técnico del ingeniero software.


Problema de los patrones

Los patrones, no llevan de forma directa a la reutilización del código, aunque dicha reutilización se facilita mediante su uso.

La integración de los patrones en el proceso de desarrollo se hace todavía de forma manual.

El número de patrones identificados es cada vez más grande. Las clasificaciones actuales no siempre sirven de guía para decidir cual usar.


El número de combinaciones patrones estilos y atributos que se dan en la práctica son incontables.

Los patrones se validan por la experiencia y el debate, no mediante la aplicación de técnicas formales

Problema de los patrones


Cómo seleccionar un patrón de diseño

Considerar cómo los patrones de diseño solucionan problemas de diseño.

Buscar las intenciones de cada patrón.Estudiar cómo se interrelacionan los

patrones.Estudiar patrones de propósito similar.Examinar la causa de un rediseño.Considerar que debería ser variable en un

diseño.


Cómo usar un patrón de diseño1. Leer el patrón una vez para tener una

visión general2. Volver y estudiar la estructura, los

participantes y las colaboraciones3. Ver un ejemplo concreto codificado

del patrón4. Elegir nombres para los participantes

del patrón que sean significativos en el contexto de la aplicación


5. Definir las clases6. Definir nombres específicos de la

aplicación para las operaciones en el patrón.

7. Implementar las operaciones que realizarán las responsabilidades y colaboraciones del patrón.

Cómo usar un patrón de diseño


Antipatrón de diseño

Antipatrón es un patrón de diseño que invariablemente conduce a una mala solución para un problema.

Al documentarse los antipatrones, además de los patrones de diseño, se dan argumentos a los diseñadores de sistemas para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.



El estudio de los antipatrones es muy útil porque sirve para no escoger malos caminos en el desarrollo de sistemas, teniendo para ello una base documental y así evitar usar simplemente la intuición. Además proporciona una denominación común a problemas que facilita la comunicación entre diferentes desarrolladores.



Mejor conocido como “objeto todopoderoso”. Se presenta cuando una clase es muy grande tanto en atributos y/o en métodos.

Entre más grande son las clases es más difíciles de mantener, reusar y probar. Su gran tamaño puede perjudicar el tiempo de carga. Generalmente son el resultado de un mal diseño o de sistemas legados.


Referencias:

http://codecriticon.com/introduccion-patrones-diseno/

https://msdn.microsoft.com/es-es/library/bb972240.aspx

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/820


clase 4 - programación iv - bsi1100

Technology