Clase 4 - Programación IV - BSI1100

ESCUELA DE INGENIERÍA DE
SISTEMAS INFORMÁTICOS
UNIVERSIDAD LATINA
LIC. 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ón
Contexto
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.

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ón
Es 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ño
Paquetes,
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 objetos
Decorator: 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 concurrente
Patrones de interfaz gráfica
Patrones de organización de código
Patrones de optimización de código
Patrones de robustez de código
Patrones 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ño
1. Leer el patrón una vez para tener una visión
general
2. Volver y estudiar la estructura, los
participantes y las colaboraciones
3. Ver un ejemplo concreto codificado del
patrón
4. Elegir nombres para los participantes del
patrón que sean significativos en el contexto
de la aplicación

5. Definir las clases
6. 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/c
ontenido/recurso/820

Clase 4 - Programación IV - BSI1100

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Clase 4 - Programación IV - BSI1100

Similar a Clase 4 - Programación IV - BSI1100 (20)

Último

Último (20)

Clase 4 - Programación IV - BSI1100