Observer

Observador es un patrn de diseo que define una dependencia del tipo uno-a-muchos entre
objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a todos
los dependientes.

Objetivo
Definir una dependencia uno-a-muchos entre objetos, de tal forma que cuando el objeto cambie de
estado, todos sus objetos dependientes sean notificados automticamente. En definitiva,
normalmente, usaremos el patrn Observador cuando un elemento quiere estar pendiente de
otro, sin tener que estar encuestando de forma permanente si ste ha cambiado o no.

Aplicabilidad
Puede pensarse en aplicar este patrn cuando una modificacin en el estado de un objeto requiere
cambios de otros, y no deseamos que se conozca el nmero de objetos que deben ser cambiados.
Tambin cuando queremos que un objeto sea capaz de notificar a otros objetos sin hacer ninguna
suposicin acerca de los objetos notificados y cuando una abstraccin tiene dos aspectos
diferentes, que dependen uno del otro; si encapsulamos estos aspectos en objetos separados
permitiremos su variacin y reutilizacin de modo independiente.

Estructura

Participantes
Tendremos sujetos concretos cuyos cambios pueden resultar interesantes a otros y observadores
a los que al menos les interesa estar pendientes de un elemento y en un momento dado,
reaccionar ante sus notificaciones de cambio. Todos los sujetos tienen en comn que un conjunto
de objetos quieren estar pendientes de ellos. Cualquier elemento que quiera ser observado tiene
que permitir indicar:
1. Estoy interesado en tus cambios.
2. Ya no estoy interesado en tus cambios.
El observable tiene que tener, adems, un mecanismo de aviso a los interesados.

A continuacin tenemos a los participantes de forma desglosada:

Sujeto (Subject):
El sujeto concreto proporciona una interfaz para agregar (attach) y eliminar (detach)
observadores. El Sujeto conoce a todos sus observadores.

Observador (Observer):
Define el mtodo que usa el sujeto para notificar cambios en su estado (update/notify).

Sujeto Concreto (ConcreteSubject):

Mantiene el estado de inters para los observadores concretos y los notifica cuando
cambia su estado. No tienen porque ser elementos de la misma jerarqua.

Observador Concreto (ConcreteObserver):

Mantiene una referencia al sujeto concreto e implementa la interfaz de actualizacin, es

decir, guardan la referencia del objeto que observan, as en caso de ser notificados de
algn cambio, pueden preguntar sobre este cambio.

Facade
El patrn fachada viene motivado por la necesidad de estructurar un entorno de programacin y
reducir su complejidad con la divisin en subsistemas, minimizando las comunicaciones y
dependencias entre stos.

Consideraciones para su aplicacin

Se aplicar el patrn fachada cuando se necesite proporcionar una interfaz simple para un
subsistema complejo, o cuando se quiera estructurar varios subsistemas en capas, ya que las
fachadas seran el punto de entrada a cada nivel. Otro escenario proclive para su aplicacin surge
de la necesidad de desacoplar un sistema de sus clientes y de otros subsistemas, hacindolo ms
independiente, portable y reutilizable (esto es, reduciendo dependencias entre los subsistemas y
los clientes).

Estructura
Se puede ver en la siguiente figura:

A continuacin, se muestra un ejemplo:

Participantes
Fachada (Facade): conoce qu clases del subsistema son responsables de una determinada
peticin, y delega esas peticiones de los clientes a los objetos apropiados del subsistema.
Subclases (ModuleA, ModuleB, ModuleC...): implementan la funcionalidad del subsistema.
Realizan el trabajo solicitado por la fachada. No conocen la existencia de la fachada.

Colaboraciones
Los clientes que se comunican con el subsistema enviando peticiones al objeto Fachada, el cual
las reenva a los objetos apropiados del subsistema.
Los objetos del subsistema realizan el trabajo final ,y la fachada hace algo de trabajo para pasar de
su interfaz a las del subsistema.
Los clientes que usan la fachada no tienen que acceder directamente a los objetos del subsistema.

Usos conocidos (Problemas/Soluciones)

Problema: Un cliente necesita acceder a parte de la funcionalidad de un sistema ms complejo.

Definir una interfaz que permita acceder solamente a esa funcionalidad.

Problema: Existen grupos de tareas muy frecuentes para las que se puede crear cdigo ms
sencillo y legible.

Definir funcionalidad que agrupe estas tareas en funciones o mtodos sencillos y

claros.

Problema: Una biblioteca es difcilmente legible.

Crear un intermediario ms legible.

Problema: Dependencia entre el cdigo del cliente y la parte interna de una
biblioteca.

Crear un intermediario y realizar llamadas a la biblioteca slo o, sobre todo, a travs

de l.
Problema: Necesidad de acceder a un conjunto de APIs que pueden adems
tener un diseo no muy bueno.

Crear una API intermedia, bien diseada, que permita acceder a la funcionalidad de
las dems.
Problema: Muchas clases cliente quieren usar varias clases servidoras, y
deben saber cul es exactamente la que le proporciona cada servicio. El
sistema se volvera muy complejo, porque habra que relacionar todas las
clases cliente con todas y cada una de las clases servidoras.

Crear una o varias clases Facade, que implementen todos los servicios, de modo que
o todos los clientes utilicen esa nica clase, o que cada grupo de clientes use la
fachada que mejor se ajuste a sus necesidades.

Abstract Factory
Contexto: Debemos crear diferentes objetos, todos pertenecientes a la misma familia. Por ejemplo:
las bibliotecas para crear interfaces grficas suelen utilizar este patrn y cada familia sera un
sistema operativo distinto. As pues, el usuario declara un Botn, pero de forma ms interna lo que
est creando es un BotnWindows o un BotnLinux, por ejemplo.
El problema que intenta solucionar este patrn es el de crear diferentes familias de objetos.
El patrn Abstract Factory est aconsejado cuando se prev la inclusin de nuevas familias de
productos, pero puede resultar contraproducente cuando se aaden nuevos productos o cambian
los existentes, puesto que afectara a todas las familias creadas.

La estructura tpica del patrn Abstract Factory es la siguiente:

Cliente: La clase que llamar a la factora adecuada ya que necesita crear uno de los objetos
que provee la factora, es decir, Cliente lo que quiere es obtener una instancia de alguno de los
productos (ProductoA, ProductoB).

AbstractFactory: Es la definicin de la interfaces de las factoras. Debe de proveer un mtodo

para la obtencin de cada objeto que pueda crear. ("crearProductoA()" y "crearProductoB()")

Factoras Concretas: Estas son las diferentes familias de productos. Provee de la instancia
concreta de la que se encarga de crear. De esta forma podemos tener una factora que cree
los elementos grficos para Windows y otra que los cree para Linux, pudiendo poner
fcilmente (creando una nueva) otra que los cree para MacOS, por ejemplo.

Producto abstracto: Definicin de las interfaces para la familia de productos genricos. En el

diagrama son "ProductoA" y "ProductoB". En un ejemplo de interfaces grficas podran ser
todos los elementos: Botn, Ventana, Cuadro de Texto, Combo... El cliente trabajar
directamente sobre esta interfaz, que ser implementada por los diferentes productos
concretos.

Producto concreto: Implementacin de los diferentes productos. Podra ser por ejemplo
"BotnWindows" y "BotnLinux". Como ambos implementan "Botn" el cliente no sabr si est
en Windows o Linux, puesto que trabajar directamente sobre la superclase o interfaz.

Factory Method
En diseo de software, el patrn de diseo Factory Method consiste en utilizar una clase constructora
(al estilo del Abstract Factory) abstracta con unos cuantos mtodos definidos y otro(s) abstracto(s): el
dedicado a la construccin de objetos de un subtipo de un tipo determinado. Es una simplificacin
del Abstract Factory, en la que la clase abstracta tiene mtodos concretos que usan algunos de los
abstractos; segn usemos una u otra hija de esta clase abstracta, tendremos uno u otro
comportamiento.

Estructura
Las clases principales en este patrn son el creador y el producto. El creador necesita crear instancias
de productos, pero el tipo concreto de producto no debe ser forzado en las subclases del creador,
porque las posibles subclases del creador deben poder especificar subclases del producto para utilizar.

La solucin para esto es hacer un mtodo abstracto (el mtodo de la fbrica) que se define en el
creador. Este mtodo abstracto se define para que devuelva un producto. Las subclases del creador
pueden sobrescribir este mtodo para devolver subclases apropiadas del producto...

Singleton
El patrn de diseo singleton (instancia nica) est diseado para restringir la creacin de objetos
pertenecientes a una clase o el valor de un tipo a un nico objeto.
Su intencin consiste en garantizar que una clase slo tenga una instancia y proporcionar un punto
de acceso global a ella.
El patrn singleton se implementa creando en nuestra clase un mtodo que crea una instancia del
objeto slo si todava no existe alguna. Para asegurar que la clase no puede ser instanciada
nuevamente se regula el alcance del constructor (con atributos como protegido o privado).
La instrumentacin del patrn puede ser delicada en programas con mltiples hilos de ejecucin. Si
dos hilos de ejecucin intentan crear la instancia al mismo tiempo y esta no existe todava, slo
uno de ellos debe lograr crear el objeto. La solucin clsica para este problema es utilizarexclusin
mutua en el mtodo de creacin de la clase que implementa el patrn.
Las situaciones ms habituales de aplicacin de este patrn son aquellas en las que dicha clase
controla el acceso a un recurso fsico nico (como puede ser el ratn o un archivo abierto en modo
exclusivo) o cuando cierto tipo de datos debe estar disponible para todos los dems objetos de la
aplicacin.

El patrn singleton provee una nica instancia global gracias a que:

La propia clase es responsable de crear la nica instancia.

Permite el acceso global a dicha instancia mediante un mtodo de clase.

Declara el constructor de clase como privado para que no sea instanciable directamente.

Composite
El patrn Composite sirve para construir objetos complejos a partir de otros ms simples y
similares entre s, gracias a la composicin recursiva y a una estructura en forma de rbol.
Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz
comn, se tratan todos de la misma manera.

Problema que soluciona

Imaginemos que necesitamos crear una serie de clases para guardar informacin acerca de una
serie de figuras que sern crculos, cuadrados y tringulos. Adems necesitamos poder tratar
tambin grupos de imgenes porque nuestro programa permite seleccionar varias de estas figuras
a la vez para moverlas por la pantalla.
En principio tenemos las clases Crculo, Cuadrado y Tringulo, que heredarn de una clase padre
que podramos llamar Figura e implementarn todas la operacin pintar(). En cuanto a los grupos
de Figuras podramos caer en la tentacin de crear una clase particular separada de las anteriores
llamada GrupoDeImgenes, tambin con un mtodo pintar().
Problema. Esta idea de separar en clases privadas componentes (figuras) y contenedores
(grupos) tiene el problema de que, para cada uno de los dos atributos, el mtodo pintar() tendr
una implementacin diferente, aumentando la complejidad del sistema.

Implementacin
El patrn Composite da una solucin elegante a este problema, de la que adems resulta en una
implementacin ms sencilla. A la clase Figura la llamaramos Grfico y de ella extenderan
tanto Crculo, Cuadrado y Tringulo, como GrupoDeImgenes. Adems, sta ltima tendra una
relacin todo-parte de multiplicidad * con Grfico: un GrupoDeImgenes contendra varios Grficos,
ya fuesen stos Cuadrados, Tringulos, u otras clases GrupoDeImgenes. As, es posible definir a
un grupo de imgenes recursivamente. Por ejemplo, un objeto cuya clase
es GrupoDeImgenes podra contener un Cuadrado, un Tringulo y otro GrupoDeImgenes, este
grupo de imgenes podra contener un Crculo y un Cuadrado. Posteriormente, a este ltimo grupo
se le podra aadir otro GrupoDeImgenes, generando una estructura de composicin recursiva en
rbol, por medio de muy poca codificacin y un diagrama sencillo y claro.

Proxy
El patrn Proxy es un patrn estructural que tiene como propsito proporcionar un subrogado o
intermediario de un objeto para controlar su acceso

Motivacin
Para explicar la motivacin del uso de este patrn veamos un escenario donde su aplicacin sera
la solucin ms adecuada al problema planteado. Consideremos un editor que puede incluir
objetos grficos dentro de un documento. Se requiere que la apertura de un documento sea rpida,
mientras que la creacin de algunos objetos (imgenes de gran tamao) es cara. En este caso no
es necesario crear todos los objetos con imgenes nada ms abrir el documento porque no todos
los objetos son visibles. Interesa por tanto retrasar el coste de crear e inicializar un objeto hasta
que es realmente necesario (por ejemplo, no abrir las imgenes de un documento hasta que no
son visibles). La solucin que se plantea para ello es la de cargar las imgenes bajo demanda.
Pero, cmo cargar las imgenes bajo demanda sin complicar el resto del editor? La respuesta es
utilizar un objeto proxy. Dicho objeto se comporta como una imagen normal y es el responsable de
cargar la imagen bajo demanda.

Aplicabilidad
El patrn proxy se usa cuando se necesita una referencia a un objeto ms flexible o sofisticada que
un puntero. Dependiendo de la funcin que se desea realizar con dicha referencia podemos
distinguir diferentes tipos de proxies:

proxy remoto: representante local de un objeto remoto.

proxy virtual: crea objetos costosos bajo demanda (como la clase ImagenProxy en el
ejemplo de motivacin).

proxy de proteccin: controla el acceso al objeto original (ejemplo de proxy de proteccin: [1])

proxy de referencia inteligente: sustituto de un puntero que lleva a cabo operaciones

adicionales cuando se accede a un objeto (ej. contar nmero de referencias al objeto real,
cargar un objeto persistente bajo demanda en memoria, control de concurrencia de acceso tal
como bloquear el objeto para impedir acceso concurrente, ).

Participantes
La clase Proxy : mantiene una referencia al objeto real (en el siguiente ejemplo se le
denomina _sujetoReal) y proporciona una interfaz idntica al sujeto (la clase Sujeto). Adems
controla el acceso a dicho objeto real y puede ser el responsable de su creacin y borrado.
Tambin tiene otras responsabilidades que dependen del tipo de proxy:

proxy remoto: responsable de codificar una peticin y sus argumentos, y de enviarla al objeto
remoto.

proxy virtual: puede hacer cach de informacin del objeto real para diferir en lo posible el
acceso a este.

proxy de proteccin: comprueba que el cliente tiene los permisos necesarios para realizar la
peticin.

La clase Sujeto: define una interfaz comn para el proxy (Proxy) y el objeto real (de la
clase SujetoReal), de tal modo que se puedan usar de manera indistinta.
La clase SujetoReal: clase del objeto real que el proxy representa.

Colaboraciones
Dependiendo de la clase de proxy, el objeto proxy redirige las peticiones al objeto real que
representa.
Ejemplos de funcionamiento:

Diagrama de clases para un ejemplo del patrn proxy.

Diagrama de secuencia para un ejemplo en el que no se utiliza el patrn proxy.

Diagrama de secuencia para un ejemplo en el que se utiliza el patrn proxy

Ejemplos comunes de la aplicacin del patrn proxy

A continuacin se presentan algunos de los ejemplos ms comunes en los que se utiliza el
patrn proxy :

Aadir acceso de seguridad a un objeto existente. El proxy determinar si el cliente puede

acceder al objeto de inters (proxy de proteccin).

Proporcionando interfaz de recursos remotos como el servicio web o recursos REST.

Coordinacin de las operaciones costosas en recursos remotos pidiendo los recursos a

distancia para iniciar la operacin tan pronto como sea posible antes de acceder a los
recursos.

Agregar una operacin segura para los subprocesos a una clase existente sin cambiar el
cdigo de la clase existente.

State
State se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.
Por ejemplo: una alarma puede tener diferentes estados, como desactivada, activada, en
configuracin. Definimos una interfaz Estado_Alarma, y luego definimos los diferentes estados.
State propone una solucin a esta complicacin, creando bsicamente, un objeto por cada estado
posible del objeto que lo llama.

Motivacin
El patrn State est motivado por aquellos objetos en que, segn su estado actual, vara su
comportamiento ante los diferentes mensajes. Como ejemplo se toma una clase TCPConection
que representa una conexin de red, un objeto de esta clase tendr diferentes respuestas segn
su estado (Listening, Close o Established). Por ejemplo la invocacin al mtodo Open de un objeto
de la clase TCPConection diferir su comportamiento si la conexin se encuentra en Close o en
Established.

Solucin
Se implementa una clase para cada estado diferente del objeto y el desarrollo de cada mtodo
segn un estado determinado. El objeto de la clase a la que le pertenecen dichos estados resuelve
los distintos comportamientos segn su estado, con instancias de dichas clases de estado. As,
siempre tiene presente en un objeto el estado actual y se comunica con este para resolver sus
responsabilidades.
La idea principal en el patrn State es introducir una clase abstracta TCPState que representa los
estados de la conexin de red y una interfaz para todas las clases que representan los estados
propiamente dichos. Por ejemplo la clase TCPEstablished y la TCPClose implementan
responsabilidades particulares para los estados establecido y cerrado respectivamente del objeto
TCPConnection. La clase TCPConnection mantiene una instancia de alguna subclase de TCPState
con el atributo state representando el estado actual de la conexin. En la implementacin de los
mtodos de TCPConnection habr llamadas a estos objetos representados por el atributo state
para la ejecucin de las responsabilidades, as segn el estado en que se encuentre, enviar estas
llamadas a un objeto u otro de las subclases de TCPState.

Participantes
1. Context(Contexto): Este integrante define la interfaz con el cliente. Mantiene una
instancia de ConcreteState (Estado Concreto) que define su estado actual
2. State (Estado):Define una interfaz para el encapsulamiento de la responsabilidades
asociadas con un estado particular de Context.
3. Subclase ConcreteState:Cada una de estas subclases implementa el comportamiento o
responsabilidad de Context.
El Contexto (Context) delega el estado especfico al objeto ConcreteState actual Un objeto Context
puede pasarse a s mismo como parmetro hacia un objeto State. De esta manera la clase State
puede acceder al contexto si fuese necesario. Context es la interfaz principal para el cliente. El
cliente puede configurar un contexto con los objetos State. Una vez hecho esto, los clientes no
tendrn que tratar con los objetos State directamente. Tanto el objeto Context como los objetos de
ConcreteState pueden decidir el cambio de estado.

Cmo funciona?
La clase Context enva mensajes a los objetos ConcreteState dentro de su cdigo para brindarle a
estos la responsabilidad que debe cumplir el objeto Context. As el objeto Context va cambiando
las responsabilidades segn el estado en que se encuentra, puesto que tambin cambia de objeto
ConcreteState al hacer dicho cambio de estado.

Cundo emplearlo?
Esta apuntado a cuando un determinado objeto tiene diferentes estados y tambin distintas
responsabilidades segn el estado en que se encuentre en determinado instante. Tambin puede
utilizarse para simplificar casos en los que se tiene un complicado y extenso cdigo de decisin
que depende del estado del objeto