UNIVERSIDAD GERARDO BARRIOS

MATERIA:

Ingeniería de software II

DOCENTE:

Lic. Carla Milagros López Vásquez

ESTUDIANTE:

Kevin Mauricio Artiga Núñez usts044913

TRABAJO

Patrones de diseño web

CARREAR:

Tec. En Ing. En sistemas y redes informáticas

FACULTAD:

Ciencia y tecnología

PATRONES DE DISEÑO WEB

PRINCIPIOS BÁSICOS DE LA USABILIDAD WEB

El diseño de sitios web deben seguir los siguientes principios:

1. Anticipación, el sitio web debe anticiparse a las necesidades del usuario.

2. Autonomía, los usuarios deben tener el control sobre el sitio web. Los usuarios sienten que

controlan un sitio web si conocen su situación en un entorno abarcable y no infinito.

3. Los colores han de utilizarse con precaución para no dificultar el acceso a los usuarios con

problemas de distinción de colores (aprox. un 15% del total).

4. Consistencia, las aplicaciones deben ser consistentes con las expectativas de los usuarios, es

decir, con su aprendizaje previo.

5. Eficiencia del usuario, los sitios web se deben centrar en la productividad del usuario, no en

la del propio sitio web. Por ejemplo, en ocasiones tareas con mayor número de pasos son más

rápidas de realizar para una persona que otras tareas con menos pasos, pero más complejas.

6. Reversibilidad, un sitio web ha de permitir deshacer las acciones realizadas

7. Ley de Bits indica que el tiempo para alcanzar un objetivo con el ratón está en función de la

distancia y el tamaño del objetivo. A menor distancia y mayor tamaño más facilidad para usar

un mecanismo de interacción.

8. Reducción del tiempo de latencia. Hace posible optimizar el tiempo de espera del usuario,

permitiendo la realización de otras tareas mientras se completa la previa e informando al

usuario del tiempo pendiente para la finalización de la tarea.

9. Aprendizaje, los sitios web deben requerir un mínimo proceso de aprendizaje y deben poder

ser utilizados desde el primer momento.

10. El uso adecuado de metáforas facilita el aprendizaje de un sitio web, pero un uso inadecuado

de estas puede dificultar enormemente el aprendizaje.

11. La protección del trabajo de los usuarios es prioritario, se debe asegurar que los usuarios

nunca pierden su trabajo como consecuencia de un error.

12. Legibilidad, el color de los textos debe contrastar con el del fondo, y el tamaño de fuente

debe ser suficientemente grande.

13. Seguimiento de las acciones del usuario. Conociendo y almacenando información sobre su

comportamiento previo se ha de permitir al usuario realizar operaciones frecuentes de manera

más rápida.

14. Interfaz visible. Se deben evitar elementos invisibles de navegación que han de ser inferidos

por los usuarios, menús desplegables, indicaciones ocultas, etc.

Otros principios para el diseño de sitios web son:

a) Los usuarios deben ser capaces de alcanzar sus objetivos con un mínimo esfuerzo y unos

resultados máximos.

b) Un sitio web no ha de tratar al usuario de manera hostil. Cuando el usuario comete un error

el sistema ha de solucionar el problema, o en su defecto sugerir varias soluciones posibles, pero

no emitir respuestas que meramente informen del error culpando al usuario.

c) En ningún caso un sitio web puede venirse abajo o producir un resultado inesperado. Por

ejemplo no deben existir enlaces rotos.

d) Un sitio web debe ajustarse a los usuarios. La libertad en el uso de un sitio web es un término

peligroso, cuanto mayor sea el número de acciones que un usuario pueda realizar, mayor es la

probabilidad que cometa un error. Limitando el número de acciones al público objetivo se

facilita el uso de un sitio web.

e) Los usuarios no deben sufrir sobrecarga de información. Cuando un usuario visita un sitio

web y no sabe dónde comenzar a leer, existe sobrecarga de información.

f) Un sitio web debe ser consistente en todos los pasos del proceso. Aunque pueda parecer

apropiado que diferentes áreas tengan diseños diferentes, la consistencia entre los diseños

facilita al usuario el uso de un sitio.

g) Un sitio web debe proveer de un feedback a los usuarios, de manera que éstos siempre

conozcan y comprendan lo que sucede en todos los pasos del proceso

Hablamos de usabilidad web -concepto clave para diseñadores- al referirnos a facilidad de

acceso, ubicación y navegación

Cómo diseñar una página web es uno de los aspectos más importantes de un sitio web y las

técnicas para que pueda ser entendible y sencillo de explorar por parte del usuario resultan

determinantes.

La usabilidad web se centra en la necesidad del usuario de tener accesibilidad web, ubicación y

navegación dentro de una página web. Que todo sea claro y estructurado para no complicar al

visitante y tener el riesgo de perderlo en pocos segundos.

El diseñador web es un personaje clave en la creación del sitio web, ya que no debe actuar no

con la estética o el gusto subjetivo como prioridades, sino más bien pensar en el usuario.

Principios de usabilidad web

El contenido de Internet tiene sus propias características con respecto a otros medios y apuesta

por textos más resumidos y atractivos. El diseño debe contar con una navegación simple y clara,

unos textos precisos y una estructura “amigable” para la mayoría de los usuarios.

Los principales conceptos en torno a la usabilidad web son los siguientes:

::. Visibilidad: Es importante que el usuario pueda reconocer los diferentes elementos de

manera sencilla, sin mayor esfuerzo.

::. Consistencia: Una información debe ser reiterada de diferentes formas pero debe ser

siempre la misma. Tiene que haber una definición en torno a los patrones de la página web y la

experiencia del usuario para no crear confusión.

::. Compatibilidad: El sitio web debe adecuarse a la forma de pensar del usuario promedio, del

cliente potencial y el público meta. En estética y funcionalidad, los procesos deben adaptarse a

las expectativas de los visitantes.

::. Eficiencia: Debes reducir el trabajo del usuario en todos los niveles, facilitar el camino para

que pueda encontrar la información que desea o que pueda retroceder en caso de hallar un

resultado indeseado. Hay que predecir los posibles pasos a seguir del visitante y prevenir los

errores.

Un buen consejos es siempre tener en cuenta quiénes serán los usuarios habituales de la página

web y así enfocar el diseño en ese camino, tomando en cuenta su experiencia y nivel de

conocimiento.

Errores de usabilidad web

Sin importar la cantidad de visitas que puede tener un sitio web o las ganancias que obtenga

por determinado servicio o producto, es fácil detectar algunos problemas para el uso del

usuario promedio.

Algunas de estas fallas de usabilidad web son las siguientes:

::. Logan ocultos: Es suficientemente complicado lograr interesar a un usuario para que se

registre en una página web, por lo que no tener un acceso visible para usuario y contraseña

::. Pop-ups: Prácticamente todos los navegadores tienen bloqueadores de pop-ups, por lo que

las ventanas emergentes han pasado a ser una molestia y no son la mejor manera de presentar

contenido.

::. Links invisibles: La navegación es una importante importante, por lo que no encontrar los

enlaces necesarios para movilizarse a través de la página web puede traer problemas

importantes.

::. Sobrecarga visual: Muchas veces, más es menos. El “ruido” visual es uno de los problemas

comunes que los diseñadores provocan o deben resolver de acuerdo con la necesidad del

cliente.

::. Menú desplegable: Ocultar opciones en un menú desplegable ahorra espacio pero complica

la navegación de los usuarios, ya que requiere un esfuerzo para fijar la posición del cursor y

seleccionar esa opción.

DISEÑO WEB FLUIDO O DISEÑO WEB LÍQUIDO

Fluid web designó o liquida web designó, es aquel que tiende a ocupar todo el ancho de la

pantalla, sea cual sea el tamaño de esta. Es un tipo de diseño menos utilizado que el anterior, ya

que requiere de mucho más trabajo por parte del diseñador web y a que si no se realiza

correctamente su resultado puede resultar bastante atractivo para tamaños de pantalla

“normales” y pequeñas, pero cuando se emplean pantallas de muchas pulgadas su estética

resulta, cuanto menos, horrible, a no ser que se utilicen técnicas como el uso de max-width para

limitar el máximo ancho aceptado por nuestro diseño. En este caso el diseñador web utiliza

porcentajes en lugar de píxeles para establecer los anchos de sus diseños, aunque también se

pueden emplear píxeles y medidas máximas y mínimas con min-whist y max-width. Por suerte

es un tipo diseño que cada vez va tomando más terreno y va sustituyendo al diseño fijo

El diseño web fluido o diseño web líquido, fluid web designó o liquida web designó, es aquel

que tiende a ocupar todo el ancho de la pantalla, sea cual sea el tamaño de esta. Es un tipo de

diseño menos utilizado que el anterior, ya que requiere de mucho más trabajo por parte del

diseñador web y a que si no se realiza correctamente su resultado puede resultar bastante

atractivo para tamaños de pantalla “normales” y pequeñas, pero cuando se emplean pantallas

de muchas pulgadas su estética resulta, cuanto menos, horrible, a no ser que se utilicen técnicas

como el uso de max-width para limitar el máximo ancho aceptado por nuestro diseño. En este

caso el diseñador web utiliza porcentajes en lugar de píxeles para establecer los anchos de sus

diseños, aunque también se pueden emplear píxeles y medidas máximas y mínimas con min-

width y max-width. Por suerte es un tipo diseño que cada vez va tomando más terreno y va

sustituyendo al diseño fijo

DISEÑO WEB HIBRIDO

Diseño web hibrido es una adaptación o combinación de dos estándares…un ejemplo de eso es

mashup

En desarrollo web, una mashup es una forma de integración y reutilización. Ocurre cuando de

una aplicación web es usada o llamada desde otra aplicación, con el fin de reutilizar su

contenido y/o funcionalidad. El uso en otra(s) fuente(s), para crear nuevos servicios simples,

visualizado en una única interfaz gráfica diferente. Por ejemplo, se pueden combinar las

direcciones y fotografías de las ramas de una biblioteca con un mapa de Google Maps para crear

un mashup de mapa.

El término implica integración fácil y rápida, a menudo usando varias API abiertas y fuentes de

datos para producir resultados enriquecidos, que no fueron necesariamente el motivo original

de producir la fuente primaria de datos.

El contenido usado en mashups es típicamente obtenido de otra fuente vía una interfaz pública

o API (web services), aunque existe gente en la comunidad que considera que los casos en que

las interfaces son privadas no deberían contar como mashups. Otros métodos de obtener

contenido para mashups incluyen Web Feeds (por ejemplo: RSS oAtom) y screen scraping.

Mucha gente experimenta con mashups usando las API de Amazon, eBay, Flickr, Google,

Microsoft, Yahoo o YouTube; lo que ha llevado a la creación de un editor mashup.

La arquitectura de los mashups está siempre compuesta de tres partes:

El proveedor de contenidos: fuente de los datos. Los datos están disponibles vía una API y

diferentes protocolos web como RSS, REST y Web Service.

El sitio mashup: es la nueva aplicación web que provee un nuevo servicio utilizando diferente

información y de la que no es dueña.

El navegador web cliente: es la interfaz de usuario del mashup. En una aplicación web, el

contenido puede ser mezclado por los web browser clientes usando lenguaje web del lado del

cliente, por ejemplo, JavaScript.

Los mashups deben ser diferenciados de simples embebidos de datos de otro sitio para formar

un documento compuesto. Un sitio que permite al usuario embeber vídeos deYoutube, por

ejemplo, no es un sitio mashup. Como ya se dijo, el sitio mismo debe acceder información

externa a él usando una API y procesar esos datos de modo que incrementen su valor para el

usuario

Los mashups se presentan actualmente en tres formas: mashups de consumidores, mashups de

datos y mashups empresariales.

El tipo más conocido es el de mashup de consumidores, que está muy bien ejemplificado por

muchas aplicaciones que utilizan Google Maps. Los mashups de este tipo combinan datos de

fuentes varias, ocultando este hecho tras una interfaz gráfica simple.

Un mashup de negocio es una combinación de todo lo anterior, enfocando en agregación de

datos y presentación y agregando adicionalmente una funcionalidad colaborativa, haciendo que

el resultado final sea una aplicación de negocio apropiada.

Mashups dentro de mashups son conocidos como “mashups monstruos”.

DISEÑO PARA WEB MÓVILES

Decálogo de consejos de usabilidad para la web móvil

A continuación voy a listar hasta 10 consejos que nos pueden ayudar a construir sitios web más

usables en dispositivos móviles. Algunos son más prácticos que otros, algunos también más

obvios que otros.

La regla fundamental: Menos es más

Debemos comenzar comentando la regla fundamental para el diseño web móvil y aunque pueda

parecer un tópico, el dicho que "Menos es más" se ajusta perfectamente a la realidad. Cuando

diseñamos para móviles nos sobra cualquier tipo de floritura, contenido superfluo o cualquier

accesorio prescindible.

Como venimos diciendo, el usuario que se conecta a nuestro sitio web desde un móvil no lo

suele hacer por entretenimiento, sino porque quiere obtener alguna información o servicio. Lo

quiere rápido, y ligero, así que debemos satisfacerle en la medida de lo posible. Cuanto menos

distracciones, mejor para el usuario y por añadidura, mejor para nosotros.

Consejos del W3C

Antes que nada quiero nombrar una fuente totalmente reconocida y recomendaros su consulta.

Se trata, nada más y nada menos que el propio Consorcio de las Tres Uves Dobles, W3C para los

amigos. Una organización que a día de hoy no necesita más presentación y que nos ofrece una

lista bastante interesante de consejos que nos ayudarán a crear webs más usables cuando se

acceden desde dispositivos.

El informe está en inglés y se llama Mobile Best Practices. Cabe señalar que, por contra de lo

que muchas veces nos tienen acostumbrados desde la W3C, en este caso el texto es bastante

sencillo de leer y de entender.

1.- Ten en cuenta la diversidad de pantallas

Como primer punto, lo más fundamental en torno de los dispositivos móviles, las sensibles

diferencias de tamaños de pantallas y de resolución. Ten en cuenta que estás diseñando para

pantallas por lo general pequeñas, pero además que existen distintos tipos de definiciones. Si

en ordenadores de escritorio ya debíamos tener en cuenta este detalle, al desarrollar para

móviles todavía cobra mayor importancia.

2.- El foco no es tu sitio

Lo dicho anteriormente, quizás los usuarios están accediendo a tu sitio mientras llevan a cabo

otras tareas, así que no vas a pretender que el visitante tenga los 5 sentidos dedicados a tu web.

Analiza qué es lo que quieres mostrar, sintetiza, llama la atención sobre los puntos que

consideres más importantes y descarta aquellos que no merezcan la pena. En la medida de lo

posible, reduce la cantidad de contenido que estás distribuyendo en tu página para móviles.

3.- El layout debe estar pensado para móviles

En la web de escritorio utilizamos rejillas que tienen 12 o 16 columnas, sin embargo, en la web

para móviles quizás con una columna tienes más que suficiente. En cualquier caso, ten en cuenta

que funcionan mejor los layouts fluidos, que se adaptan a la anchura de cada tipo de pantalla. Si

vas a utilizar varias columnas, considera 2 o 3 a lo sumo. Sin embargo, también es cierto que

algunos dispositivos como los tablets pueden soportar perfectamente layouts más complejos,

por lo que no existe una regla fija. Lo mejor sería tener varios layouts y utilizar uno u otro

dependiendo de las dimensiones de la pantalla. Más adelante veremos cómo hacer eso.

4.- La navegación en la parte de arriba no suele funcionar

En la web para escritorio es habitual tener un navegador en la parte de arriba de la página, con

un listado de las secciones principales de un sitio web. Pero debemos tener en cuenta que en

dispositivos de movilidad, con pantallas pequeñas, ese listado de links puede ocupar todo el

espacio disponible, lo que obligaría al usuario a hacer scroll para ver el contenido de la página.

Algo que no es deseable. En la portada del sitio web puede ser una buena idea mantener la

navegación en la parte de arriba del documento, pero en el resto de páginas queda mejor si la

situamos abajo.

5.- Uso responsable de las imágenes

Esa imagen que en las pantallas de los ordenadores queda tan bien, posiblemente tenga un

tamaño excesivo para visualizarse en una pantalla pequeña de un teléfono. Posiblemente la

definición de la foto sea superior a la de la pantalla de tu dispositivo, con lo que estás

desperdiciando espacio y ancho de banda para su transferencia. Usa imágenes con tamaños

adaptados a móviles y elimina determinados usos de imágenes que aportan poco o nada a la

utilidad de tu documento, como imágenes de fondo, que pueden molestar la lectura más que

otra cosa.

6.- Se trabaja con los dedos y no con el ratón

Este punto es de vital importancia, puesto que la pantalla táctil utiliza el dedo como señalador

y tiene muchas diferencias con respecto al puntero del ratón de nuestro ordenador personal.

Ten en cuenta detalles como que el espacio para hacer un tap (tap es como se llama al clic

realizado con el dedo sobre una pantalla táctil) es mayor que el que señalaríamos con el puntero

del ratón (se supone que un dedo en la pantalla ocupa entre 40 y 80 píxeles de ancho). Dicho de

otro modo, no se puede comparar la precisión de un clic con el ratón y con el dedo, que puede

cambiar mucho de una persona a otra y también la forma de posicionarlo en la pantalla. En

general tu sitio web funcionará mejor cuando pongas botones o enlaces con tamaño mayor. Así

mismo, sería recomendable dejar un mayor espacio en blanco entre los botones o enlaces de tu

sitio web.

7.- Entrada de texto en teclados virtuales

En el ordenador personal utilizamos un teclado para introducir texto, sin embargo, en

dispositivos móviles se suele usar un teclado virtual que a menudo resulta mucho más

incómodo. Este detalle y varios otros que tienen que ver con la entrada de datos en general lo

veremos en el siguiente artículo sobre usabilidad en formularios optimizados para móviles.

8.- No se dispone de plugins

Flash es el ejemplo más claro de plugin que no disponemos en todos los dispositivos y que por

tanto no deberíamos usar en páginas que queremos que se vean bien en móviles. Pero hay otros,

como los Applets de Java, Shockwave, etc. Sin olvidar que no todos tienen compatibilidad con

ciertas capacidades de scripting. Sugerir la actualización del navegador, o la instalación de otro

cliente web, no es la solución en muchos de los casos, pues no siempre el usuario tiene

oportunidad de actualizar su sistema operativo o instalar otro software para la navegación web.

9.- Los tipos de eventos cambian

El clic en pantallas táctiles se llama Tap. Realmente es un nuevo modo de llamar a la misma

cosa, pero existen otros eventos que sí tienen cambios importantes, o que no están disponibles

en las pantallas táctiles. Por ejemplo, el hover no existe al trabajar con los dedos. Además, hay

otra serie de eventos que sólo existen en móviles como deslizamiento de los dedos, zoom, girar

la pantalla etc.

10.- Existen diversas utilidades específicas que se pueden aprovechar Los dispositivos móviles

a menudo integran algunas habilidades que no se disponen en los ordenadores de escritorio,

como localización geográfica, cámaras, grabación, orientación, etc. En la mayorá de los casos

estos mecanismos sólo se disponen en aplicaciones nativas, pero gracias a HTML 5, algunos ya

están disponibles en sitios web. En el futuro la tendencia es integrar aun más estas capacidades

en la web

PATRONES CREACIONALES

La regla fundamental: Menos es más

Debemos comenzar comentando la regla fundamental para el diseño web móvil y aunque pueda

parecer un tópico, el dicho que "Menos es más" se ajusta perfectamente a la realidad. Cuando

diseñamos para móviles nos sobra cualquier tipo de floritura, contenido superfluo o cualquier

accesorio prescindible.

Como venimos diciendo, el usuario que se conecta a nuestro sitio web desde un móvil no lo

suele hacer por entretenimiento, sino porque quiere obtener alguna información o servicio. Lo

quiere rápido, y ligero, así que debemos satisfacerle en la medida de lo posible. Cuanto menos

distracciones, mejor para el usuario y por añadidura, mejor para nosotros.

Consejos del W3C

Antes que nada quiero nombrar una fuente totalmente reconocida y recomendaros su consulta.

Se trata, nada más y nada menos que el propio Consorcio de las Tres Uves Dobles, W3C para los

amigos. Una organización que a día de hoy no necesita más presentación y que nos ofrece una

lista bastante interesante de consejos que nos ayudarán a crear webs más usables cuando se

acceden desde dispositivos.

El informe está en inglés y se llama Mobile Best Practices. Cabe señalar que, por contra de lo

que muchas veces nos tienen acostumbrados desde la W3C, en este caso el texto es bastante

sencillo de leer y de entender.

La regla fundamental: Menos es más

Debemos comenzar comentando la regla fundamental para el diseño web móvil y aunque pueda

parecer un tópico, el dicho que "Menos es más" se ajusta perfectamente a la realidad. Cuando

diseñamos para móviles nos sobra cualquier tipo de floritura, contenido superfluo o cualquier

accesorio prescindible.

Como venimos diciendo, el usuario que se conecta a nuestro sitio web desde un móvil no lo

suele hacer por entretenimiento, sino porque quiere obtener alguna información o servicio. Lo

quiere rápido, y ligero, así que debemos satisfacerle en la medida de lo posible. Cuanto menos

distracciones, mejor para el usuario y por añadidura, mejor para nosotros.

Consejos del W3C

Antes que nada quiero nombrar una fuente totalmente reconocida y recomendaros su consulta.

Se trata, nada más y nada menos que el propio Consorcio de las Tres Uves Dobles, W3C para los

amigos. Una organización que a día de hoy no necesita más presentación y que nos ofrece una

lista bastante interesante de consejos que nos ayudarán a crear webs más usables cuando se

acceden desde dispositivos.

El informe está en inglés y se llama Mobile Best Practices. Cabe señalar que, por contra de lo

que muchas veces nos tienen acostumbrados desde la W3C, en este caso el texto es bastante

sencillo de leer y de entender.

Este es un patrón creacional, el problema que intenta solucionar es: la creación de diferentes

familias de objetos relacionados o que dependen entre si, sin especificar sus clases concretas.

Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen

entre si y haciendo transparente el tipo de familia concreta que se esta usando.

Se aplica principalmente a objetos. Tratan con las relaciones entre objetos, que pueden

cambiarse en tiempo de ejecución y son muy dinámicos.

Clases que participan

FabricaAbstracta: Declara una interfaz para operaciones que crean objetos productoabstractos.

FabricaConcreta: Implementa las operaciones para crear objetos producto concretos.

ProductoAbstracto: Declara una interfaz para un tipo de objeto producto.

ProductoConcreto: Define un objeto producto para que sea creado por la fábrica

correspondiente. Implementa la interfaz ProductoAbstracto.Cliente: Sólo usa interfaces

declaradas por las clases.

Ventajas

Hace fácil el intercambio de familias de productos

Porque en el momento de que requiera lo único que se debe hacer, es cambiar o mejorar una

línea de código

Fomenta la consistencia entre productos.

Encapsula la responsabilidad de creación

Porque aísla las clases concretas y ayuda a mantener un control sobre las clases de datos

Desventajas

Puede ser difícil incorporar nuevos tipos de datos. Pero esto se puede tener solución, pasando un parámetro a los métodos de creación de

productos, pero con esto sacrificaría seguridad.

Patrones relacionados

Singleton: es implementado en la fabrica concreta.

Prototype: es implementado al definir fabricas extensibles y evitar la dependencia de la interfaz

de las fabricas de los nuevos productos se puede tener un catalogo de prototipos.

Factory Method: la fábrica abstracta deja que las subclases creen los productos redefiniendo las

operaciones de creación.

Estructura

Introducción

El objetivo es conseguir que la construcción de un objeto compuesto sea independiente de su

representación, de manera que la construcción no se vea afectada por el hecho de que cambie

su forma de representación.

Intención

Construir de manera flexible un objeto complejo a partir de otro objeto complejo en una serie

de pasos

Motivación

Los objetos que dependen de un algoritmo tendrán que cambiar cuando el algoritmo cambia.

Por lo tanto los algoritmos que estén expuestos a dicho cambio deberían ser separados,

permitiendo de esta manera reutilizar algoritmos para crear diferentes representaciones.

Aplicabilidad

El patrón Builder se usa cuando:

El algoritmo para creación de un objeto complejo debe ser independiente de las partes que

conforman el objeto y cómo están ensambladas.

El proceso de construcción debe permitir diferentes representaciones del objeto que se

construye.

Participantes

Builder

Especifica una interfaz abstracta para la creación de partes de un objeto Producto.

ConcreteBuilder

Construye y ensambla las partes del producto por implementación de la interfaz Builder.

Define y guarda la ruta de la representación que crea.

Provee una interfaz para recuperación del producto.

Director

Construye un objeto usando la interfaz Builder.

Product

Representa el objeto complejo en construcción. El ConcreteBuilder construye la representación

interna del producto y define el proceso con el cual se ensambla.

Incluye las clases que definen las partes componentes, incluyendo interfaces para ensamblar

las partes dentro del resultado final.

Estructura

Colaboraciones

El Cliente crea el objeto Director y lo configura con el objeto Builder deseado.

El Director notifica al constructor cuándo una parte del producto se debe construir.

El Builder maneja los requerimientos desde el director y agrega partes al producto.

El Cliente recupera el producto desde el constructor.

Consecuencias

Permite variar la representación interna de un producto

• El Builder ofrece una interfaz al Director para construir un producto y encapsula la

representación interna del producto y cómo se juntan sus partes.

• Si se cambia la representación interna basta con crear otro Bulider que respete la interfaz.

Separa el código de construcción del de representación

• Las clases que definen la representación interna del producto no aparecen en la interfaz del

Bulider

• Cada ConcreteBuilder contiene el código para crear y juntar una clase específica de producto

• Distintos Directors pueden usar un mismo ConcreteBuilder

Da mayor control en el proceso de construcción

• Permite que el Director controle la construcción de un producto paso a paso

• Sólo cuando el producto está acabado lo recupera el director del builder

Implementación y patrones relacionados

El Builder define las operaciones para construir cada parte

• El ConcreteBuilder implementa estas operaciones

Con la Factoría Abstracta también se pueden construir objetos complejos

• Pero el objetivo del patrón Builder es construir paso a paso

• El énfasis de la Factoría Abstracta es tratar familias de objetos

El objeto construido con el patrón Builder suele ser un Composite

El Método Factoría se puede utilizar por el Builder para decidir qué clase concreta instanciar

para construir el tipo de objeto deseado

El patrón Visitor permite la creación de un objeto complejo,en vez de paso a paso, dando todo

de golpe como objeto visitante

Este es un patrón que se ocupa en la creación de objetos, sin especificar la clase de objeto que

se crear. Factory method se ocupa del problema mediante la definición de un método para crear

los objetos.

A veces, una aplicación en tiempo de ejecución, no puede anticipar la clase de objeto que se

debe crear. La aplicación puede saber que tiene que instanciar las clases, pero solo puede saber

acerca de clases abstractas, que no puede crear una instancia, Por lo tanto, la clase de

aplicaciones solo puede saber cuando tiene que instanciar un nuevo objeto de una clase, no el

tipo de la subclase a crear.

Intención

Definir una interfaz para crear objetos de tipo genérico permitiendo a las subclases decidir qué

tipo de objetos concreto crear.

Motivación

Sea un framework para la construcción de editores de documentos de distintos tipos.

Se nos presenta el dilema de que el framework es quien sabe, a través de su clase Aplicación,

cuándo se debe crear un nuevo documento, pero no sabe qué documento crear (sólo conoce a

la clase abstracta o interfaz)

La solución de este dilema es encapsular el conocimiento de cuál es la subclase concreta del

documento a crear y mover ese conocimiento fuera del framework.

Aplicabilidad

Una clase no puede anticipar el tipo concreto de objetos que debe crear

Una clase quiere que sus subclases especifiquen el tipo de objetos a crear

Estructura

Participantes

Product: define la interfaz de los objetos que el método factory va a crear.

ConcreteProduct: implementa la interfaz Product.

Creator: Declara el FactoryMethod(), el cual retorna un objeto del tipo Product(). Creator

también puede definir una implementación por defecto del FactoryMethod() y retornar un

objeto por defecto.

ConcreteCreator: Redefine el FactoryMethod() que retorna una instancia ConcreteProduct

Patrones relacionados

Template Method El patrón Factory Method es a menudo utilizado con el patrón Template

Method. Prototype: El patrón Prototype proporciona un modo alternativo para un objeto de

trabajar con otros objetos sin conocer los detalles de su construcción. El patrón Prototype

específica la clase de objetos a crear usando una instancia prototípica, y creando los objetos

mediante una copia de este prototipo.

Consecuencias

Seguir las convenciones de nombres para ayudar a otros desarrolladores a reconocer la

estructura del código.

Factory method puede ser parametrizado.

Ocultar clases concretas del cliente.

Una familia de objetos tiene que ser separados por el uso compartido de la interfaz.

Una desventaja de los Factory Methods es que los clientes deberán hacer subclases de la clase

creadora solo para crear un ConcreteProduct objeto particular.

Implementación

Convenios de nominación. Se suele usar el prefijo create.

La factoría se suele implementar como un Singleton.

El método fábrica parametrizado(y en menor medida el no parametrizado) protege de la

variación del tipo de producto concreto.

Diseñar una fábrica concreta que permita crear productos cuya definición del tipo no se conoce

en tiempo de compilación.

El objetivo es ahorrar recursos con la creación de objetos, la manera mas eficiente de tener los

objetos sin crearlos de nuevo es clonándolos.

Intención

Especifica los tipos de objetos a crear utilizando una instancia prototipo, y crea nuevos objetos

copiando esta instancia.

Motivación

En ciertos escenarios es preciso abstraer la lógica que decide que tipos de objetos utilizará una

aplicación, de la lógica que luego usarán esos objetos en su ejecución. Los motivos de esta

separación pueden ser variados, por ejemplo, puede ser que la aplicación deba basarse en

alguna configuración o parámetro en tiempo de ejecución para decidir el tipo de objetos que se

debe crear.

Aplicabilidad

Un sistema debe ser capaz de crear objetos sin conocer su clase exacta, como son creados, o que

datos representan.

Las clases serán instanciadas sin ser conocidas por el sistema hasta el tiempo de ejecución.

Los siguientes métodos para la creación de una gran variedad de objetos son indeseables:

Las clases que inicializan la creación de objetos crean directamente los objetos. Esto hace que

ellos sean conscientes y dependientes de un gran número de otras clases.

Las clases que inicializan la creación de objetos crean los objetos indirectamente a través de

una clase factory method. Un factory method que es capaz de crear una gran variedad de objetos

puede ser muy grande y difícil de mantener.

Las clases que inicializan la creación de objetos crean los objetos indirectamente a través de

una clase abstracta factory. Para que un abstracta

factory sea capaz de crear una gran variedad de objetos debe tener una gran variedad de clases

factory concretas en una jerarquía semejante a las clases que deben ser instanciadas.

Los objetos diferentes que un sistema debe crear deben ser instancias de la misma clase que

contienen diferentes estados de información o datos.

Estructura

Participantes

Cliente

La clase Cliente crea nuevos objetos pidiendo al prototipo que se clone.

Prototype

Declara la interface del objeto que se clona. Suele ser una clase abstracta.

PrototypeConcreto

Las clases en este papel implementan una operación por medio de la clonación de sí mismo.

Colaboraciones

Un cliente pide a un prototipo que se clone.

Consecuencias

Un programa puede dinámicamente añadir y borrar objetos prototipo en tiempo de ejecución.

Esta es una ventaja que no ofrece ninguno de los otros patrones de creación.

Esconde los nombres de los productos específicos al cliente.

El objeto cliente puede también ser capaz de crear nuevos objetos de tipos prototipo.

Se pueden especificar nuevos objetos prototipo variando los existentes.

La clase Cliente es independiente de las clases exactas de los objetos prototipo que utiliza.

También, la clase Cliente no necesita conocer los detalles de cómo construir los objetos

prototipo.

Los objetos de prototipo concretos implementan el interface Prototype , de esta forma el patrón

Prototype se asegura de que los objetos prototipo proporcionan un conjunto consistente de

métodos para que los objetos clientes los utilicen.

Se puede configurar una aplicación cargando clases dinámicamente.

No hay necesidad de organizar los objetos prototipos en ningún orden de jerarquía de clases.

Las subclases son reducidas.

Patrones relacionados

Composite

El patrón Prototype es utilizado a menudo con el patrón Composite.

Abstract Factory

El patrón Abstract Factory puede ser una buena alternativa al patrón

Prototype donde los cambios dinámicos que el patrón Prototype permite para los objetos

prototipo no son necesarios. Pueden competir en su objetivo, pero también pueden colaborar

entre sí.

Facade

La clase cliente normalmente actúa comúnmente como un facade que separa

las otras clases que participan en el patrón Prototype del resto del programa.

Factory Method

El patrón Factory Method puede ser una alternativa al patrón

Prototype cuando la paleta de objetos prototipo nunca contiene más de un objeto.

Decorator

El patrón Prototype es utilizado a menudo con el patrón Decorator.

Implementación

Todas las clases en Java heredan un método de la clase Object llamado clone. Un método clone

de un objeto retorna una copia de ese objeto. Esto solamente se hace para instancias de clases

que dan permiso para ser clonadas. Una clase da permiso para que su instancia sea clonada si,

y solo si, ella implementa el interface Cloneable.

Si va a variar el número de prototipos se puede utilizar un administrador de prototipos.

Cómo implementar la operación clone de los objetos prototipo es otra importante característica

de la implementación. Hay dos estrategias básicas para implementar la operación clone:

1. Copia superficial significa que las variables de los objetos clonados contienen los mismos

valores que las variables del objeto original y que todas las referencias al objeto son a los

mismos objetos. En otras palabras, la copia superficial copia solamente el objeto que será

clonado, no los objetos a los que se refiere.

2. Copia profunda significa que las variables de los objetos clonados contienen los mismos

valores que las variables del objeto original, excepto que estas variables que se refieren a

objetos realizan copias de los objetos referenciados por el objeto original. En otras palabras, la

copia profunda copia el objeto que será clonado y los objetos a los que se referencia.

Implementar la copia profunda puede ser delicado.

Necesitarás decidir si quieres hacer copia profunda o superficial de los objetos copiados

indirectamente. También necesitarás ser cuidadoso con el manejo de las referencias circulares.

La copia superficial es más fácil de implementar porque todas las clases heredan un método

clone de la clase Object que hace esto. Sin embargo, a menos que una clase de objetos

implemente el interface Cloneable, el método clone rechazará trabajar. Si todos los objetos

prototipo que tu programes utilizarán clonarse a sí mismos por copia superficial, puedes

ahorrar tiempo declarando un interface Prototype que extienda el interface Cloneable. De esta

forma todas las clases que implementen el interface Prototype también implementarán el

interface Cloneable.

Este es un patrón que garantiza que una clase solo tenga una única instancia, y provee un punto

de acceso global a esta, haciendo así que todos los objetos utilicen una instancia de la clase,

utilicen la misma instancia.

En las aplicaciones a veces se hace necesario acceder a un objeto único, lo primero que se piensa

es, en que se necesita una variable global, pero no asegura que no podamos instanciar más de

una vez un objeto de esa clase. La solución es hacer que la clase sea la responsable de controlar

la existencia de una única instancia.

Intención

Garantiza que una clase sólo tenga una instancia y proporciona un punto de acceso global a ella.

Motivación

¿Cómo aseguro que una clase tenga solamente una instancia y que la instancia sea fácilmente

accesible? .Una variable global hace un objeto accesible, pero no puede esperar usted de

instanciar objetos múltiples. Una solución es hacer que la clase misma sea responsable de

garantizar que sea instanciada una única vez. La clase puede asegurar que ninguna otra

instancia puede ser creada (Interceptando los pedidos de crear nuevos objetos), y puede

proveer una manera hacerlo/serlo acceda al ejemplo. Éste es el patrón Singleton.

Aplicabilidad

Deba haber exactamente una instancia de una clase y ésta deba ser accesible a los clientes desde

un punto de acceso conocido.

La única instancia debería ser extensible mediante herencia y los clientes deberían ser capaces

de utilizar una instancia extendida sin modificar su código.

Estructura

¿Como se crea la clase?

El constructor de la clase debe ser privado o protegido. No puede ser público.

Para almacenar nuestra instancia debemos crear un atributo que sea estático y privado. No

puede ser protegido, ni público.

Hacemos un método estático de clase para crear el punto global de acceso a nuestra única

instancia. Este método debe retornar la instancia única.

Participantes

Define una operación Instancia que permite que los clientes accedan a su única instancia.

Instancia es una operación de clase.

Puede ser responsable de crear su única instancia.

Patrones relacionados

Puedes utilizar el patrón Singleton con muchos otros patrones. En particular, el patrón es

utilizado con los patrones Abstract Factory, Builder, y Prototype.

El patrón Singleton tiene alguna similitud con el patrón Cache Management.

Consecuencias

Existe exactamente una instancia de una clase Singleton.

Otras clases que quieran una referencia a la única instancia de la clase Singleton conseguirán

esa instancia llamando al método static getInstancia de la clase. Controla el acceso a la única

instancia.

Tener subclases de una clase Singleton es complicado y resultan clases imperfectamente

encapsuladas. Para hacer subclases de una clase Singleton, deberías tener un constructor que

no sea privado. También, si quieres definir una subclase de una clase Singleton que sea también

Singleton, querrás que la subclase sobrescriba el método getInstancia de la clase Singleton. Esto

no será posible, ya que métodos como getInstancia deben ser static. Java no permite

sobrescribir los métodos static.

Implementacion

Para forzar el carácter de una clase Singleton, debes codificar la clase de tal forma que

prevengas que otras clases creen directamente instancias de la clase. El modo de realizarlo es

declarar todos los constructores de la clase privados o protegidos. Tener cuidado de declarar al

menos un constructor privado. Si una clase no declara ningún constructor, entonces un

constructor público es automáticamente generado por ella.

Una variación común del patrón Singleton ocurre en situaciones donde la instancia de un

Singleton podría no ser necesaria. En estas situaciones, puedes posponer la creación de la

Instancia hasta la primera llamada a getInstancia.

Otra variación sobre el patrón Singleton desciende del hecho de que la política de Instanciación

de una clase está encapsulada en el método de la clase getInstancia. Debido a esto, es posible

variar la política de creación. Una posible política es tener el método

getInstancia que retorne alternativamente una de las dos intancias o crear periódicamente una

nueva instancia para ser retornada por getInstancia. Es decir se puede permitir un número

variable de instancias.

PATRONES DE COMPORTAMIENTO

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

Los patrones de diseño pretenden:

· Proporcionar catálogos de elementos reusables en el diseño de sistemas software.

· Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y

solucionados anteriormente.

· Formalizar un vocabulario común entre diseñadores.

· Estandarizar el modo en que se realiza el diseño.

· Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando

conocimiento ya existente.

Asimismo, no pretenden:

· Imponer ciertas alternativas de diseño frente a otras.

· Eliminar la creatividad inherente al proceso de diseño.

· No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo

problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso

particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Categorías de patrones

· Según la escala o nivel de abstracción:

· Patrones de arquitectura: Aquéllos que expresan un esquema organizativo estructural

fundamental para sistemas de software.

· Patrones de diseño: Aquéllos que expresan esquemas para definir estructuras de diseño

(o sus relaciones) con las que construir sistemas de software.

· Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o

entorno concreto.

Estructuras o plantillas de patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se

expresen uniformemente y puedan constituir efectivamente un medio de comunicación

uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas

ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes

apartados:

· Nombre del patrón: nombre estándar del patrón por el cual será reconocido en

la comunidad (normalmente se expresan en inglés).

· Clasificación del patrón: creacional, estructural o de comportamiento.

· Intención: ¿Qué problema pretende resolver el patrón?

· También conocido como: Otros nombres de uso común para el patrón.

· Motivación: Escenario de ejemplo para la aplicación del patrón.

· Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.

· Estructura: Diagramas de clases oportunos para describir las clases que intervienen en

el patrón.

· Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que

participan en el patrón.

· Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.

· Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la

aplicación del patrón.

· Implementación: Técnicas o comentarios oportunos de cara a la implementación del

patrón.

· Código de ejemplo: Código fuente ejemplo de implementación del patrón.

· Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

· Patrones relacionados: Referencias cruzadas con otros patrones.

Características:

· Las plantillas son de bajo costo.

· Se utililizan en diferentes tipos de aplicaciones: web, escritorio, app móviles.

· El código es reutilizable; comprada la plantilla, se adquiere la propiedad intelectual de la

misma.

Patrones orientados a objetos

(Análisis y diseño a objetos)

Tareas del patrón:

· Identificación de casos de uso.

· Definición del modelo conceptual.

· Especificación de diagrama de servicio.

· Definición de clases.

Identificación de casos de uso

Definición: el caso de uso describe una funcionalidad parcial del sistema que se desarrolla

Notación: Diagrama de casos de uso.

Modelo conceptual

Abarca las abstracciones del mundo real en términos de claves y objetos.

El Modelo Conceptual ilustra:

• Conceptos (Objetos) en el dominio del problema.

• Es el instrumento (artefacto) más importante de

Crear en el AOO.

• Es la representación de cosas del mundo real y

NO de componentes de software. En él NO se

Definen operaciones.

• Puede representarse mediante un diagrama de

Estructura estático (notación UML).

Características

El modelo conceptual se convierte en el insumo básico del diagrama de clases.

Diagrama de secuencia

Describe espacial y temporal el flujo normal de eventos entre los diferentes conceptos

presentes en el sistema.

Definición de clases:

Se especifican las clases presentes en el sistema y se parametrizan (métodos y atributos

para cada clase).

Patrones de diseño vista-control

Ofrece un número mayor de ventajas con respecto al patrón orientado a objetos.

Tiene tres componentes (capas de desarrollo)

Capa vista: en términos de la interfaz de usuario.

Capa lógica: se almacena e implementan los objetos de la aplicacion, tiene dos presentaciones

Capa conceptos

Ejemplo: Usuario y contraseña

Capa conceptos

Ejemplo: Nombre del usuario y comparar contraseña .

3-Capa de almacenamiento: gestión de archivos, Bases de datos.

Ejemplo: gestión de archivos con los nombres de los usuarios El patrón vista-control sugiere

un diseño TOP-DOWN con una importancia centrada en la interfaz de usuario la cual debe ser

obtenida a partir de los requisitos del producto software.

Requisitos

Es una necesidad que tiene un usuario o cliente de un producto software

Necesidad se traduce en términos de funciones.

Características:

Todos los requisitos no deben dar posibilidad a la ambigüedad

Los requisitos deben permitir entender el domino de la aplicaron

Los requisitos se deben obtener del cliente o usuario

Diagrama de casos de uso

Actor: fuente o sumidero "Externo" al sistema que interactúa con el desencadenado una serie

de eventos interrelacionados.

Atributo del sistema: Son requisitos no funcionales, que son necesidades propias del producto

software.

Aplicación

Medio físico (Hardware) memoria, etc.

Tolerancia a fallos.

Metáfora de la interfaz: Describe el estándar utilizado para desarrollar la interfaz.

Técnicas para levantar requisitos:

1-Entrevista.

2-JAD (Joint applications Development).

3-Sketch ans story board.

4-Concept Moping.

5-Brainstorming (lluvia de ideas).

6-Layout.

7-Use case.

8-Patrones.

9-Chek List.

Patrón Arquitectónico de capas

La arquitectura del SI es una descripción de los

Subsistemas y componentes, y las relaciones entre ellos.

· Determina:

· La organización estructural del SI.

· La selección de los elementos estructurales.

· Las interfaces entre ellos.

· El comportamiento de los componentes.

· Un componente es una parte física y reemplazable de un sistema.

Catálogo parcial de patrones arquitectónicos

· Llamada y retorno

· estilo más usado en los grandes SI

· Descomposición modular jerárquica

· Orientado a objetos

· En capas

· Centrado en los datos

· permite la manipulación compartida de datos

· Repositorio

· Pizarra

· Flujo de datos

· permite la transformación incremental de los datos

· Batch secuencial

· Tubos y filtros

· Modelo – vista – controlador

· para sistemas interactivos

Patroness Grasp (General reponsability assignament software pattern)

En diseño orientado a objetos, GRASP son patrones generales de software para asignación de

responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns" .

Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas

prácticas" de aplicación recomendable en el diseño de software.

Patrones de software para asignar responsabilidades

Función:

Definir en las clases de análisis.

1-La clase con mayor jerarquía para implementar en ella los métodos.

Clase patrón

2-Asignar responsabilidades a las clases.

Elementos para definir un patrón Grasp.

Diagrama de paquetes

Diagrama de secuencia

Diagrama de paquetes

Paquete: Agrupación de casos de uso con aspectos similares en su funcionalidad .

ejemplo:

diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos

en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-

trace diagrams", "event scenarios" o "timing diagrams"

Patrones Grasp

· Patrón experto.

· Patrón creador.

· Patrón bajo acoplamiento.

· Patrón alta cohesión.

· Patrón controlador.

Patrón experto

Determina en un modelo conceptual (Diagrama de clases) la clase que posee la mayor jerarquía

para asignarle una responsabilidad "La responsabilidad que se quiera evaluar y debe ser

implementado por un método"

Ventajas del patrón experto

Garantizar el encapsulamiento de la información

Facilita el bajo acoplamiento en las aplicaciones

Patrón creador

Se utiliza cuando se quiere a partir de una clase con alta jerarquía obtener clases descendiente

o instancias a partir de las clases obtenidas.

Tipos de clases:

Clases abstractas (1)

Clases concretas (2)

(1) son las clases que dan origen a otras solamente.

(2) son las clases a partir de las cuales se pueden obtener instancias.

El patrón creador define dos estructuras dentro de la jerarquía

Estructura AKO

Estructura APO

AKO(A King of): una clase de

APO(A Punto of): una parte de

Patron bajo Acoplamiento

Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso

de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en

el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases

1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro

módulo. (En lenguajes de alto nivel es muy raro)

2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.

3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que

determina la lógica de ejecución del mismo.

Patron alto cohesión

Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la

medida de lo posible) relacionada con la clase.

1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.

2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de

ejecución, sólo una de ellas será llevada a cabo.

3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el

deber ser ejecutadas “al mismo tiempo”.

4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que

corresponden a una secuencia de pasos propia del “producto”.

5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del

“producto” y todas afectan a los mismos datos.

6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto

de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo

típico: OBJETOS

7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único

objetivo a cumplir, se dice que tiene Cohesividad Funcional.

Patrón controlador

Es el encargado de definir las estructuras para los patrones experto y creador .

Experto: Diagrama de secuencia.

Creadas: Jerarquía: AKO, APO.

Patrones Gof

Gang-of-Four (“pandilla de los cuatro”) Descritos en el libro Design Patterns(Gama1995)

definieron un catálogo con 23 Patrones básicos. Los patrones de diseño (design patterns) son

la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y

otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea

considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber

comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es

que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en

distintas circunstancias.

Relación de principales patrones GoF (Gang Of Four)

Patrones creacionales

Abstract Factory (Fábrica abstracta): Permite trabajar con objetos de distintas familias de

manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia

concreta que se esté usando.

Builder (Constructor virtual): Abstrae el proceso de creación de un objeto complejo,

centralizando dicho proceso en un único punto.

Factory Method (Método de fabricación): Centraliza en una clase constructora la creación de

objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el

subtipo que crear.

Prototype (Prototipo): Crea nuevos objetos clonándolos de una instancia ya existente.

Singleton (Instancia única): Garantiza la existencia de una única instancia para una clase y la

creación de un mecanismo de acceso global a dicha instancia.

Patrones estructurales

Adapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de

otro modo no podría utilizarla.

Bridge (Puente): Desacopla una abstracción de su implementación.

Composite (Objeto compuesto): Permite tratar objetos compuestos como si de un simple se

tratase.

Decorator (Envoltorio): Añade funcionalidad a una clase dinámicamente.

Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo

de interfaces de un subsistema.

Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen

idéntica información.

Proxy: Mantiene un representante de un objeto.

Patrones de comportamiento

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben

llevar los mensajes para que los objetos realicen la tarea indicada.

Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha

operación sin necesidad de conocer el contenido de la misma.

Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como

las herramientas necesarias para interpretarlo.

Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente

de la implementación de estos.

Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas

clases, pero que funcionan como un conjunto.

Memento (Recuerdo): Permite volver a estados anteriores del sistema.

Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que

cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos

que dependen de él.

State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.

Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir

cuál utilizar en tiempo de ejecución.

Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo,

delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan

ciertos pasos de un algoritmo sin cambiar su estructura.

Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin

modificar las clases sobre las que opera.

PATRONES ESTRUCTURALES

Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría

utilizarla.

Motivacion

Necesitamos reutilizar clases ajenas paranuestro sistema, pero aunque la funcionalidad de

estas clases es la que deseamos, la interfaz no es compatible. Si no podemos o no queremos

modificar las clases a reutilizar, necesitamos hacerlas compatibles con nuestro sistema.

Aplicabilidad

Se quiere utilizar una clase que llame a un método a través de una interface, pero quieres

utilizarlo con una clase que no implementa ese interface. Modificar esa clase que implementa

el interface no es una opción por un par de razones:

1. No tienes el código fuente de la clase.

2. La clase es una clase de propósito general, y es inapropiado para ella implementar un

interface par un propósito específico.

Se quiere determinar dinámicamente que métodos de otros objetos llama un objeto.

Se quiere realizarlo sin que el objeto llamado tenga conocimientos de la otra clase de objetos.

Estructura

Participantes

Target: Define la interfaz especifica del dominio en el que se quiere hacer uso de la clase que se

adapta.

Client: Utiliza objetos que implementan la interfaz definida por el target.

Adaptee: Presenta su interfaz original, que es la que se tiene que adaptar.

Adapter: Adapta la interfaz del objeto adaptado a la definida por el target.

Colaboraciones

Esta sección está compuesta por máximo seis (6) palabras o frases que describan los tópicos,

áreas o temas más importantes del trabajo. Deben estar ordenadas alfabéticamente. La

selección de palabras clave apropiadas permitirá la inclusión del artículo en índices

internacionales así como la ubicación rápida del artículo por parte de un lector interesado.

Consecuencias

El cliente y las clases Adaptee permanecen independientes unas de las otras.

El patrón Adapter introduce una in dirección adicional en un programa . Como cualquier otra

in dirección, contribuye a la dificultad implicada en la compresión del programa.

Se puede utilizar una clase Adapter para determinar cuales de los métodos de un objeto llama

otro objeto.

Adaptadores de clase y el objeto tienen diferentes ventajas y desventajas. A class adapter Una

clase adaptador

Adaptee se adapta al objetivo de la comisión a una clase concreta adaptador. Como

consecuencia de ello, una clase

adaptador no funciona cuando se quiere adaptar una clase y todas sus subclases.

Adaptador permite anular algunas de Adaptee el comportamiento, ya que el adaptador es una

subclase de Adaptee.

sólo introduce un objeto, y no puntero indirección adicional es necesaria para llegar a la

adaptee.

Un objeto adaptador

permite a un único adaptador de trabajar con muchas Adaptees-es decir, la Adaptee sí mismo y

todas sus subclases

(si procede). El adaptador también puede agregar funcionalidad a todos los Adaptees a la vez.

Adaptador se refieren a la subclase más que la propia Adaptee

Implementación

La implementación de una clase Adapter es más bien sencilla. Sin embargo, una cuestión que

deberías considerar cuando implementes el patrón Adapter es como los objetos adapter

conocen que instancia de la clase Adaptee llamar. Hay dos métodos:

1. Pasar una referencia a los objetos cliente como parámetro a los costructores de los objetos

adapter o a uno de sus métodos. Esto permite al objeto adapter ser utilizado con cualquier

instancia o posiblemente muchas instancias de la clase Adaptee.

Hacer la clase Adapter una clase interna de la clase Adaptee. Esto simplifica la asociación entre

el objeto adapter y el objeto adaptee haciendolo automático.

También hace la asociación inflexible.

Código ejemplo

public interface ListModel {

int getSize();

Object getElementAt(int index);

}

public interface TableModel {

public int getRowCount();

// obtener número de filas

public int getColumnCount();

// obtener número de columnas

public Object getValueAt(int fil, int col);

// retorna valor del elemento fila fil y columna col

public String getColumnName(int col);

// retorna nombre de la columna col

}

Usos conocidos

El API de Java no incluye ningún objeto adapter público que este listo para utilizar. Incluye

clases tales como java.awt.event.WindowAdapter que pretenden ser heredadas más que

utilizarse directamente. La idea es que hay algunos interfaces escuchadores de eventos, tales

como WindowListener, que declaran varios métodos. En muchos casos no todos los métodos

necesitan ser implementados. El interface WindowListener declara ocho métodos que son

llamados para proporcionar notificación sobre los ocho tipos diferentes de eventos de la

ventana. A menudo uno o dos de estos tipos de eventos son de interés. Los métodos que

corresponden a los eventos que no son de interés normalmente están dando implementaciones

de no hacer nada. La clase WindowAdapter implementa el interface WindowListener e

implementa los ocho métodos con implementaciones de no hacer nada. Una clase Adapter que

hereda la clase WindowAdapter necesita implementar solamente los métodos que

corresponden a los eventos que son de interés. Hereda las implementaciones de no hacer nada

para el resto.

Patrones relacionados

Facade

La clase Adapter proporciona un objeto que actúa como un intermediario para llamar a los

métodos entre los objetos cliente y uno de los otros objetos que no conocen a los objetos cliente.

El patrón Facade proporciona un objeto que actúa como un intermediario para llamar a los

métodos entre los objetos cliente y múltiples objetos que no conocen a los objetos cliente.

Iterator

El patrón Iterator es un versión especializada del patrón Adapter para acceder secuencialmente

al contenido de una colección de objetos.

Proxy

El patrón Proxy, como el patrón Adapter, utiliza un objeto que es un sustituto por otro objeto.

Sin embargo, un objeto proxy tiene el mismo interface que el objeto por el que es sustituido.

Strategy

El patrón Strategy es estructuralmente similar al patrón Adapter. La diferencia esta en el

objetivo. El patrón Adapter permite a un objeto cliente exportar su función deseada

originalmente para llamar al método de los objetos que implementan un interface particular. El

patrón Strategy proporciona objetos que implementan un interface particular con el propósito

de alterar o determinar el comportamiento de un objeto cliente.

Bridge

Intención

desacopla una abstracción de su implementación para que puedan variar independientemente.

Motivación

Cuando queremos que un objeto cambie su comportamiento, según cambia su estado, se

presenta el problema de la complejidad de código.

Aplicabilidad

Se usa el patrón Bridge cuando:

Se desea evitar un enlace permanente entre la abstracción y su implementación. Esto puede ser

debido a que la implementación debe ser seleccionada o cambiada en tiempo de ejecución.

Tanto las abstracciones como sus implementaciones deben ser extensibles por medio de

subclases. En este caso, el patrón Bridge permite combinar abstracciones e implementaciones

diferentes y extenderlas independientemente.

Cambios en la implementación de una abstracción no deben impactar en los clientes, es decir,

su código no debe tener que ser recompilado.

(En C++) Se desea esconder la implementación de una abstracción completamente a los

clientes. En C++, la representación de una clase es visible en la interface de la clase.

Se desea compartir una implementación entre múltiples objetos (quizá usando contadores), y

este hecho debe ser escondido a los clientes.

Estructura

Participantes Abstraction define una interface abstracta. Mantiene una referencia a un objeto de tipo

Implementor.

RefinedAbstraction extiende la interface definida por Abstraction

Implementor define la interface para la implementación de clases. Esta interface no se tiene que

corresponder exactamente con la interface de Abstraction; de hecho, las dos interfaces pueden

ser bastante diferente. Típicamente la interface Implementor provee sólo operaciones

primitivas, y Abstraction define operaciones de alto nivel basadas en estas primitivas.

ConcreteImplementor implementa la interface de Implementor y define su implementación

concreta.

Colaboraciones

Abstraction emite los pedidos de los clientes a su objeto Implementor.

Consecuencias

Un objeto puede cambiar su implementación en tiempo de ejecución.

Cambios en la implementación no requerirán compilar de nuevo la clase Abstracción y sus

clientes.

Se mejora la extensibilidad.

Se ocultan detalles de implementación a los clientes.

Implementación

Sólo un Implementor: en situaciones donde existe sólo una implementación, crear una clase

Implementor abstracta no es necesario. Esto es un caso especial del patrón; hay una relación

uno-a-uno entre Abstraction e Implementor. Sin embargo, esta separación es aún muy útil

cuando un cambio en la implementación de una clase no debe afectar a sus clientes existente,

es decir, ellos no deben ser recompilados, sólo relinkeados. En C++, la interface de la clase

Implementor puede ser definida en un archivo header privado el cual no es proveído a los

clientes. Esto permite esconder una implementación de una clase completamente de sus

clientes.

Creando el objeto Implementor adecuado: ¿Cómo, cuándo y dónde que clase Implementor

instanciar cuando hay más de una?Si Abstraction conoce todas las clases ConcreteImplementor

puede instanciar una de ellas en su constructor; puede decidir cuál instanciar dependiendo de

los parámetros del constructor.

Otra aproximación es elegir una implementación inicial por defecto y cambiarla después acorde

al uso. También es posible delegar la decisión a otro objeto en conjunto.

Compartiendo implementadores: el estilo Handle/Body en C++ puede ser usado para compartir

implementaciones de muchos objetos. Body almacena una cuenta de referencia que la clase

Handle incrementa y decrementa. Usando herencia múltiple. Se puede usar herencia múltiple

en C++ para asociar una interfaz con su implementación.

Creamos una clase Abstracción padre que sea abstracta, además de abstracciones concretas

mediante clases que heredan de ella. Por otro lado se tienen las clases que implementan la

funcionalidad con una estructura similar: una clase ImplementaciónAbstracta padre, y todas las

clases hijas necesarias que implementan la funcionalidad de todas las maneras necesarias. La

relación se da entre la clase abstracta Abstracción y la clase abstracta Implementación,

delegando la primera la implementación en la segunda, que a su vez la delega en las

implementaciones concretas.

Intención

Componer objetos en estructuras de árbol para representar jerarquías parte-todo.

Composite permite a los clientes tratar cada uno de los objetos y composiciones de objetos de

manera uniforme.

Motivación

El problema que trata

Para constituir diagramas complejos desde componentes

simples en casos como un editor de dibujos, diseñador de

circuitos

Los objetos primitivos y los contenedores de ellos están en

diferentes maneras, aunque los clientes tratan ambos en la

misma manera.

Aplicabilidad

Cuando necesitamos representar la relación parte-todo

Cuando queramos que los clientes olviden la diferencia entre

las composiciones de objetos y los objetos individuales

Estructura

Participantes

Componente

Declara la interfaz para los clientes puedan acceder a lo objetos en la composición

Implementa comportamientos por defectos para todas las clases

Hoja

Representa los objetos hoja en la composición. No tienen hijos.

Define el comportamiento de los objetos primitivos en la composición

Compuesto

Define el comportamiento para los componentes que tienen

hijos

.

Almacena los componentes hijos

Implementa operaciones relacionadas a los hijos en la interfaz

de Componente

. Cliente

Manipula los objetos en la composición a través de la interfaz

de la clase Componente

.

Colaboraciones

Existen colaboraciones entre el cliente y

Componente

El cliente utiliza la interfaz para interactuar

con los objetos en la composición

Si el recibidor es una hoja: la petición se

trata directamente

Si el recibidor es un Compuesto: la petición

se pasa a sus hijos

Puede tener más operaciones extras

Consecuencias

Se define una jerarquía de clases con objetos

primitivos y compuestos

Simplifica las tareas del cliente. Puede tratar un

compuesto como un objeto primitivo

Facilita añadir nuevos componentes sin modificar

la estructura ni los códigos de clientes

Desventajas:

El diseño de programa puede ser demasiado

general

Difícil de restringir los componentes de un

compuesto.

Implementación

Temas para considerar en la implementación:

Referencias explícitas al padre

Es conveniente a tener la referencia al padre para simplificar el recorrido y administración

hacia arriba

Compartir componentes

Para ahorrar espacio de almacenamiento

Será difícil a compartir cuando el componente tiene un sólo

padre

La solución aparece en el patrón Flyweight

Maximizar la interfaz de Componente.

Es bueno a definir más operaciones posibles en la clase

Componente tanto para Compuesto como para Hoja

Definir operaciones por defectos en Componente y luego las

subclases puedan redefinirlas si son necesarias.

Dónde declarar las operaciones para administrar los hijos

Definir en la raíz (Componente): mejor transparencia peor

seguridad porque los clientes pueden hacer cosas raras

Definirlas en Compuesto: mejor seguridad pero pierde la

transparencia

Una solución: verificar en la interfaz si lo que pide es un

Compuesto o una hoja.

Código ejemplo

public abstract class Componente

{

protected String nombre;

public Componente (String nombre)

{

this.nombre = nombre;

}

abstract public void Agregar(Componente c);

abstract public void Remover(Componente c);

abstract public void Mostrar(int profundidad);

}

class Compuesto extends Componente

{

private ArrayList hijo = new ArrayList();

public Compuesto (String name)

{

super(name);

}

@Override

public void Agregar(Componente componente)

{

hijo.add(componente);

}

@Override

public void Remover(Componente componente)

{

hijo.remove(componente);

}

@Override

public void Mostrar(int profundidad)

{

System.out.println(nombre + " nivel: " + profundidad);

for (int i = 0; i < raiz =" new" comp =" new" l =" new" style="font-weight: bold;" size="4">Usos

conocidos

n Java:

· las clases java.awt.Component(Componente)

· java.awt.Container(Contenedor)

· java.awt.Panel(Contenedor concreto)

· java.awt.Button(Boton)

Patrones relacionados

Chain of Responsibility: para crear enlace entre la

clase componente y su padre

Decorator: se suelen utilizar con composite.

Normalmente tienen una clase pariente en comúm

Flyweight: nos permite compartir componentes, pero

sin referencias a su pariente

Iterator: se puede utilizar para recorrer los

compuestos

Visitor: puede localizar operaciones y

comportamientos sin distribuirlos entre las clases de

Compuesto y Hoja

Decorator

Intención

Fija responsabilidades adicionales a un objeto dinámicamente. Decoreirtors provee una

alternativa flexible a las subclasses para extender la funcionalidad.

Motivación

A veces se desea adicionar responsabilidades a un objeto pero no a toda la clase. Las

responsabilidades se pueden adicionar por medio de los mecanismos de Herencia, pero este

mecanismo no es flexible porque la responsabilidad es adicionada estáticamente. La solución

flexible es la de rodear el objeto con otro objeto que es el que adiciona la nueva responsabilidad.

Este nuevo objeto es el Decorator.

Aplicabilidad

Añadir objetos individuales de forma dinámica y transparente

Responsabilidades de un objeto pueden ser retiradas

Cuando la extensión mediante la herencia no es viable

Hay una necesidad de extender la funcionalidad de una clase, pero no hay razones para

extenderlo a través de la herencia.

Hay la necesidad de extender dinámicamente la funcionalidad de un objeto y quizás quitar la

funcionalidad extendida.

Estructura

Participantes

Component

Define la interface de los objetos a los que se les pueden adicionar responsabilidades

dinámicamente.

ConcreteComponent

Define el objeto al que se le puede adicionar una responsabilidad.

Decorator

Mantiene una referencia al objeto Component y define una interface de acuerdo con la interface

de Component.

ConcreteDecorator

Adiciona la responsabilidad al Component.

Colaboraciones

Decorator envía las solicitudes a su componente de objeto. Opcionalmente puede realizar

operaciones adicionales antes y después del envío de la solicitud.

Consecuencias

Ventajas

1.Es más flexible que la Herencia estática.

2.Permite que la adicion de nuevas responsabilidades (nuevas clases de Decorators)

independiente de las clases los Objetos que ellas extienden.

Desventajas

1.Un Decorator y su Component no son idénticos. Desde el punto de vista de la identidad de los

objetos, un DecoratorComponent no es identico al Component. Por esto no se puede confiar en en la identidad de los objetos cuando se usan Decorators

2.El patrón Decorator hace que hayan muchos objetos pequeños que son muy parecidos.

Implementación

El patrón Decorator soluciona este problema de una manera mucho más sencilla y extensible.

Se crea a partir de Ventana la subclase abstracta VentanaDecorator y, heredando de ella,

BordeDecorator y BotonDeAyudaDecorator. VentanaDecorator encapsula el comportamiento

de Ventana y utiliza composición recursiva para que sea posible añadir tantas "capas" de

Decorators como se desee. Podemos crear tantos Decorators como queramos heredando de

VentanaDecorator.

Proporcionar una interfaz unificada a un conjunto de interfaces en un subsistema. Fachada

define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.

Motivación

Minimizar la comunicación y las dependencias entre subsistemas

Aplicabilidad

El uso de este patrón esta recomendado para

Simplicar el uso y comprensión de una librería software.

Encapsular un interfaz de librería poco amigable en un interfaz más coherente o mejor

estructurado.

Centralizar las dependencias externas hacia la librería en uno o pocos puntos de entrada.

Estructura

Participantes

Fachada

subsistema o sabe que las clases son responsables de una solicitud.

delegados a las solicitudes de cliente subsistema objetos.

subsistema de clases implementar la funcionalidad del subsistema.

manejar el trabajo asignado por la Fachada objeto.

no tienen conocimiento de la fachada, es decir, no mantener las referencias a la misma.

Colaboraciones

Los clientes se comunican con el subsistema mediante el envío de peticiones a la fachada, que

reenvía a los subsistema objeto (s). A pesar de que el subsistema de objetos de realizar el

trabajo real, la fachada puede tener que hacer su propio trabajo de traducir su interfaz a las

interfaces del subsistema.

Los clientes que usan la fachada no tiene acceso a su subsistema de objetos directamente.

Consecuencias

la ventaja del patrón facade es que proporciona una interfaz mas simple para un sistema

complejo sin reducir las opciones proporcionadas por el conjunto del sistema. Esta interfaz

protege al cliente de la sobreabundancia de opciones.

El patrón Facade traduce las peticiones del cliente a los subsistema que pueden cumplir esas

peticiones. La mayor parte de las veces, una petición sera delegada en mas de un sistema. Como

el cliente Solo interactúa con el facade, el funcionamiento interno puede ser modificado,

mientras que el cliente del facade puede permanecer igual.

El patrón Facade fomenta el bajo acoplamiento entre el cliente y los subsistemas. También

puede ser utilizado para reducir el acoplamiento entre los subsistemas. Todos los subsistemas

pueden tener su propio Facade, y las otras partes del sistema pueden utilizar ese Facade para

comunicarse con el subsistema.

Implementación

Se puede reducir aún más el acoplamientohaciendo que la fachada sea una clase abstracta, de

forma que se pueda escogerentre distintas implementaciones del subsistema

Las clases Font y Graphics de las librerías estandar de Java que proporcionan la funcionalidad

básica para manipulación de fuentes y graficos aislando al usuario, en las operaciones más

comunes, de la complejidad subyacente. Otros ejemplos incluyen determinados interfaces de

librerías GIS o librerías matemáticas.

Patrones relacionados

Abstract factory : para simplificar el acceso a los distintos objetos creados por la fabrica , esta

también puede crear un objeto facade para todos ellos.

Mediator: los patrones mediator y facade son muy parecidos . La diferencia reside en la

intención y en la implementación. El patrón mediator ayuda a facilitar la comunicación entre

los componentes y sus comportamientos adicionales.

Singleton: el patrón facade utiliza el patrón Singleton para garantizar un punto de entrada único

y globalmente accesible para un subsistema.

Flyweight

Intención

Compartir estados para soportar un gran número de objetos pequeños aumentando la

eficiencia en espacio.

Motivación

El patrón flyweight describe como almacenar un gran número de objetos sin un gran coste.

Para conseguir esto se utilizan objetos que almacenan los estados compartidos y que pueden

ser usados por varios objetos simultáneamente.

Aplicabilidad

Se debe aplicar este patrón cuando se cumplen todas estas características:

Se utiliza un gran número de objetos

El coste de almacenamiento es alto debido a la cantidad de objetos

La mayoría de los estados de los objetos pueden ser creados como comunes.

Muchos objetos pueden ser reemplazados por unos pocos una vez que han sido borrados los

estados no comunes.

La aplicación no depende de la identidad de los objetos.

Estructura

Participantes

Flyweight

Declara una interfaz a través de la cual los flyweights pueden recibir y actuar sobre los estados

no compartidos.

ConcreteFlyweight

Implementa la interfaz Flyweight y almacena los estados compartidos, si los hay. Un objeto

ConcreteFlyweight debe ser compartible. Cualquier estado que almacene debe ser intrínseco;

es decir, debe ser independiente de su contexto.

UnsharedConcreteFlyweight

No todas las subclases de Flyweight tienen por qué ser compartidas. La interfaz Flyweight

permite que se comparta; no lo fuerza. Es común que los objetos de esta clase tengan hijos de

la clase ConcreteFlyweight en algún nivel de su estructura.

FlyweightFactory

Crea y gestiona los objetos flyweight.

Garantiza que los objetos flyweight se comparten de forma apropiada. Cuando un cliente

solicita un flyweight, el objeto de la clase FlyweightFactory proporciona una instancia existente,

o crea una.

Client

Contiene referencias a los flyweights.

Calcula o almacena los estados no compartidos de los flyweights.

Colaboraciones

Un objeto flyweight debe ser clasificado como compartido o no compartido. Los compartidos

se almacenan en el objeto ConcreteFlyweight; los no compartidos se almacenan o se calculan

en el objeto Cliente. Los clientes pasan este estado al objeto flyweight cuando invocan sus

operaciones.

Los clientes no deberían instanciar objetos de la clase ConcreteFlyweight directamente. Deben

obtenerlos exclusivamente del objeto FlyweightFactory para garantizar que son compartidos

apropiadamente.

Consecuencias

A primera vista , la ventaja que se obtiene es que se reduce el numero de objetos que hay que

gestionar. Esto puede ahorrar mucho espacio, tanto en memoria como en los dispositivos de

almacenamiento en caso de que sean objetos persistentes.

Se ahorra mas espacio aun si la información de contexto para los objetos Flyweight se calcula

en vez de tener la almacenada, sin embargo , esto nos lleva al inconveniente de este patrón: el

costo en tiempo de ejecución.

En lugar de almacenar muchos objetos, los clientes tienen que calcular el contexto y

proporcionar esa información a los objetos Flyweight. Los Flyweight utilizan esta información

para proporcionar funciones. Si se maneja menos objetos y se implementa correctamente, se

incrementa el rendimiento en tiempo de ejecución . Obsérvese que si hay, poca información de

contexto y el objeto Flyweight es grande , el ahorro es significativo.

Implementación

Crear una clase PelotaFlyweight, que contendrá la información común (radio y color) y otra

clase PelotaConcreta, que contendrá las coordenadas concretas de cada pelota y una referencia

a un objeto de tipo PelotaFlyweight.

Al crearse instancias de PelotaConcreta, se les deberá proveer de referencias a la instancia de

PelotaFlyweight adecuada a nuestras necesidades.

En este caso solamente tendríamos una instancia de PelotaFlyweight, puesto que hemos dicho

que todas nuestras pelotas tienen el mismo radio y color, pero pensando en un ejemplo en el

que tuviéramos varios grupos de pelotas, y dentro de cada uno de los cuales se compartieran el

radio y el color, se puede utilizar Flyweight conjuntamente con el patrón Factory, de tal modo

que este último, en el momento en que se le soliciten instancias de PelotaConcreta con

determinadas características (mismo radio y color que el solicitado), compruebe si ya existe un

PelotaFlyweight con ese radio y color, y devuelva esa referencia o, en caso de que no exista, la

cree y la registre. El patrón Factory se encargaría de gestionar los PelotaFlyweight existentes.

Proporcionar un sustituto o marcador de posición de otro objeto para controlar el acceso a ella.

Motivación

Diferir el coste de crear un objeto hasta que sea necesario usarlo: creación bajo demanda.

Un editor de documentos que incluyen objetos gráficos.

¿Cómo ocultamos que una imagen se creará cuando se necesite?: manejar el documento

requiere conocer información sobre la imagen.

Hay situaciones en las que un cliente no referencia o no puede referenciar a un objeto

directamente, pero necesita interactuar con él.

Un objeto proxy puede actuar como intermediario entre el objeto cliente y el objeto destino.

El objeto proxy tiene la misma interfaz como el objeto destino.

El objeto proxy mantiene una referencia al objeto destino y puede pasarle a él los mensajes

recibidos (delegación).

Retrasar la operación de una clonación de una tabla hasta conocer que es realmente necesaria.

Se desea clonar la tabla para evitar mantener un bloqueo un largo período de tiempo: operación

costosa. Se puede crear una clase que encapsule la tabla y sólo clone cuando sea necesario.

Mantenimiento de los servicios ante los fallos.

Materialización perezosa de tuplas en objetos.

Aplicabilidad

Siempre que hay necesidad de referenciar a un objeto mediante una referencia más rica que un

puntero o una referencia normal.

Situaciones comunes;

Proxy acceso remoto (acceso a un objeto en otro espacio de direcciones)

Proxy virtual (crea objetos grandes bajo demanda)

Proxy para protección (controlar acceso a un objeto)

Referencia inteligente (smart reference, proporciona operaciones adicionales)

Estructura

Participantes

Sujeto:

Define la interfaz 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 interfaz idéntica a la del sujeto, de manera que un Proxy pueda ser sustituido

por el sujeto real.

Controla el acceso al sujeto real, y puede ser responsable de su creación y borrado.

Colaboraciones

Proxy reenvía las solicitudes de RealSubject en su caso, dependiendo del tipo de proxy.

Consecuencias

Introduce un nivel de indirección para:

Un proxy remoto oculta el hecho que objetos residen en diferentes espacios de direcciones.

Un proxy virtual tales como crear o copiar un objeto bajo demanda.

Un proxy para protección o las referencias inteligentes permiten realizar tareas de control

sobre los objetos accedidos.

Implementación

Tenemos un objeto padre Asunto del que heredan otros dos:AsuntoReal y Proxy, todos ellos tienen un método petición(). El cliente llamaría al método petición() de Asunto, el cual pasaría

la petición a Proxy, que a su vez instanciaría AsuntoReal y llamaría a su petición().

Esto nos permite controlar las peticiones a AsuntoReal mediante el Proxy, por ejemplo

instanciando AsuntoReal cuando sea necesario y eliminándolo cuando deje de serlo.

Sistemas:

Un servidor proxy es un equipo intermediario situado entre el sistema del usuario e Internet.

Puede utilizarse para registrar el uso de Internet y también para bloquear el acceso a una sede

Web.

El servidor de seguridad del servidor proxy bloquea algunas redes o páginas Web por diversas

razones. En consecuencia, es posible que no pueda descargar el entorno de ejecución de Java

(JRE) o ejecutar algunos applets de Java.

Servidores proxy: Funcionan como servidor de seguridad y como filtro de contenidos. Son un

mecanismo de seguridad implementado por el ISP o los administradores de la red en un

entorno de Intranet para desactivar el acceso o filtrar las solicitudes de contenido para ciertas

sedes Web consideradas ofensivas o dañinas para la red y los usuarios. Mejoran el rendimiento.

Guardan en la memoria caché las páginas Web a las que acceden los sistemas de la red durante

un cierto tiempo. Cuando un sistema solicita la misma página web, el servidor proxy utiliza la

información guardada en la memoria caché en lugar de recuperarla del proveedor de

contenidos. De esta forma, se accede con más rapidez a las páginas Web.