PATRONES
DE DISEÑO
Logro de
Aprendizaje
Al finalizar la sesión de aprendizaje, el estudiante elabora un mapa conceptual
con información relevante a Patrones de Diseño, haciendo uso de herramientas
colaborativas, demostrando conocimiento y dominio del tema.
INTRODUCCIÓN
Un patrón de diseño es un camino para diseñar la solución de un tipo
particular de problema.
Soluciones bien documentadas que los expertos aplican para
solucionar nuevos problemas .
Han sido utilizadas con éxito
en el pasado.
INTRODUCCIÓN
La idea que hay detrás de los patrones de diseño es:
Desarrollar una forma estandarizada para representar soluciones
generales de problemas que se encuentran comúnmente en el
desarrollo de software.
BENEFICIOS
Nos muestran como construir sistemas con buenas cualidades de diseño
OO.
No nos dan código, nos dan soluciones generales a problemas de diseño
Es solo un modo conveniente de re-utilizar código orientado a objetos
(OO) entre proyectos y entre programadores.
BENEFICIOS
No son inventados.
Permiten a alguna parte del sistema variar independientemente de las
otras partes
Proporcionan un lenguaje común.
BREVE HISTORIA
La idea de patrones de software originalmente viene del campo de la
Arquitectura.
Christopher Alexander escribió dos libros revolucionarios que describen
patrones en la arquitectura de edificios y planeamiento urbano:
A Pattern Language: Towns, Buildings, Construction (Oxford
University Press, 1977)
The Timeless Way of Building (Oxford University Press, 1979).
Las ideas presentadas en estos libros son aplicables a un número de campos
fuera de la arquitectura, incluyendo el desarrollo de software.
BREVE HISTORIA
A principios de 1990, Erich Gamma, Richard Helm, John Vlissides, y
Ralph Johnson empezaron a trabajar en uno de los libros de
computación mas influyentes de la ultima década: Design Patterns.
Publicado en 1994 y frecuentemente llamado “Gang of Four,” o GoF
book, popularizó la idea de patrones .
El GoF book uso C++ y Smalltalk para sus ejemplos.
DEFINICIONES
“Cada patrón describe un problema que ocurre una y otra vez en
nuestro entorno y describe también el núcleo de la solución al problema,
de forma que puede utilizarse un millón de veces sin tener que hacer dos
veces lo mismo.” [Christopher Alexander - arquitecto/urbanista]
“Patrones de diseño son soluciones recurrentes a problemas de diseño
que vemos una y otra vez” [Smalltalk Companion]
“Patrones de diseño constituyen un conjunto de reglas que describen
como realizar ciertas tareas en el desarrollo real de software”
DEFINICIONES
“Un patrón maneja un problema de diseño recurrente que surge en
situaciones especificas de diseño y presenta una solución a este
problema” [Buschmann and Meunier, et al., 1996]
“Un patrón de diseño es una descripción de clases y objetos
comunicándose entre sí adaptada para resolver un problema de diseño
general en un contexto particular” [Gamma]
DESCRIPCIÓN DE PATRONES
Nombre descriptivo para el patrón.
Debe responder a la pregunta Que hará este patrón por usted?
Incluir una exposición del problema.
Una explicación de como el patrón soluciona el problema.
Lista de las ventajas, inconvenientes y compromisos asociados con el
uso de los patrones.
PATRONES J2EE
Es muy comun que una aplicacion web este construida con muchos
componentes de software de diferente tipo.
Cómo organizamos todo esto?
Qué pasa si los requerimientos
cambian?
Cómo hacemos que esto se ejecute rapido?
PATRONES J2EE
Muchos desarrolladores han estado usando contenedores J2EE para
resolver los mismos problemas con los que probablemente tengamos
que tratar:
Encontraron temas recurrentes en la naturaleza de los problemas
que estaban tratando.
Se les ocurrio una solucion reusable a estos problemas
Estas soluciones han sido usadas, testeadas y refinadas por otros
desarrolladores.
REQUERIMIENTOS NO FUNCIONALES
Una aplicacion web debe satisfacer los requerimientos funcionales.
Una vez que estamos seguros que el sistema soporta todos los casos de uso, es muy
probable que nos enfrentemos con otro tipo de requerimientos: requerimientos no
funcionales.
Performance.
Si nuestra aplicacion web es lenta, perderemos usuarios.
Modularidad
Si diferentes piezas de nuestra aplicación deben ejecutarse en diferentes
servidores al mismo tiempo.
REQUERIMIENTOS NO FUNCIONALES
Flexibilidad
Necesitamos cambiar nuestro sistema sin pasar por un ciclo de gran desarrollo.
Mantenebilidad
Necesitamsos que nuestro sistema sea fácil de mantener.
Extensibilidad
Nuestro sistema debe poder crecer a futuro con un minimo esfuerzo.
PRINCIPIOS DE DISEÑO DE SOFTWARE
Patrones dependen en gran medida de principios comunes de diseño de software.
CODIFICAR A INTERFACES
Una interfaces es un tipo de contrato entre dos objetos.
Un enorme beneficio de las interfaces es el polimorfismo: muchas clases pueden implementar
la misma interface.
SEPARACIÓN DE RESPONSABILIDADES Y COHESION
Cuando especializamos las capacidades de nuestro componentes de software, estos serán mas
fáciles de crear, mantener y reutilizar.
Una consecuencia natural de separar responsabilidades es que la cohesion tiende a
incrementar.
PRINCIPIOS DE DISEÑO DE SOFTWARE
OCULTAR COMPLEJIDAD
Ocultar la complejidad frecuentemente va de la mano con la separacion de responsabilidades.
Este enfoque simplifica todos los componentes del sistema que estan involucrados de aluguna
manera.
BAJO ACOPLAMIENTO
Por su propia naturaleza, sistemas OO involucran objetos que se hablan unos a otros.
Codificando a interfaces, podemos reducir el numero de cosas que una clase necesita conocer
sobre otra clase para que se comuniquen.
PRINCIPIOS DE DISEÑO DE SOFTWARE
PROXY REMOTO
Objetos java en diferentes maquinas, con sus propias memorias(heap) separadas, tienen que
comunicarse unos con otros
Aprovechando el poder de interfaces, un proxy remoto es un objeto local para el objeto «cliente»
que pretende ser un objeto remoto.
En lo que respecta al cliente este esta hablando a un objeto local.
INCREMENTAR CONTROL DECLARATIVO
Es una caracteristica potente de los contenedores J2EE.
Este control declarativo es implementado comunmnete usando el descriptor de despliegue de la
aplicacion (DD).
Modificando el DD tenemos el poder de cambiar el comportamineto del sistema sin cambiar
codigo.
