Abstract Factory

>Contexto y Problema
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.

>Aspecto esttico

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.

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 utilizar exclusin 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.

>Ejemplo de implementacin en JAVA:

public class Singleton {
private static Singleton INSTANCE = new Singleton();
// El constructor privado no permite que se genere un constructor por defecto.
// (con mismo modificador de acceso que la definicin de la clase)
private Singleton() {}
public static Singleton getInstance() {
return INSTANCE;
}
}

Adapter
El patrn Adapter (Adaptador) se utiliza para transformar una interfaz en otra, de tal modo
que una clase que no pudiera utilizar la primera, haga uso de ella a travs de la segunda.
Usar el patrn Adapter cuando:

Se desea usar una clase existente, y su interfaz no se iguala con la necesitada.

Cuando se desea crear una clase reusable que coopera con clases no relacionadas,
es decir, las clases no tienen necesariamente interfaces compatibles.

>Estructura

>Participantes

Target define la interfaz especfica del dominio que Client usa.

Client colabora con la conformacin de objetos para la interfaz Target.

Adaptee define una interfaz existente que necesita adaptarse

Adapter adapta la interfaz de Adaptee a la interfaz Target

>Implementacin
package Structural_patterns;
public class AdapterWrapperPattern {
public static void main(String args[]){
Guitar eGuitar = new ElectricGuitar();
eGuitar.onGuitar();
eGuitar.offGuitar();
Guitar eAGuitar = new ElectricAcousticGuitar();
eAGuitar.onGuitar();
eAGuitar.offGuitar();
}

public abstract class Guitar{

abstract public void onGuitar();
abstract public void offGuitar();
}
public class ElectricGuitar extends Guitar{
public void onGuitar() {
System.out.println("Playing Guitar");
}
public void offGuitar() {
System.out.println("I'm tired to play the guitar");
}
}
/**
* Class to Adapter/Wrapper
*/
public class AcousticGuitar{

public void play(){

System.out.println("Playing Guitar");
}
public void leaveGuitar(){
System.out.println("I'm tired to play the guitar");
}
}
/**
* we Adapter/Wrapper AcousticGuitar into
* ElectricAcousticGuitar to adapt into the GuitarModel
*/
public class ElectricAcousticGuitar extends Guitar{
AcousticGuitar acoustic = new AcousticGuitar();
public void onGuitar() {
acoustic.play();
}
public void offGuitar() {
acoustic.leaveGuitar();
}
}
}

Decorator
El patrn Decorator responde a la necesidad de aadir dinmicamente funcionalidad a un
Objeto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera
incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la
primera.
Un ejemplo para poder ver la aplicabilidad del patrn decorador podra ser el siguiente:

Disponemos de una herramienta para crear interfaces grcas, que permite aadir
funcionalidades como bordes o barras de desplazamiento a cualquier componente de
la interfaz.

Una posible solucin sera utilizar la herencia para extender las responsabilidades de
la clase. Si optamos por esta solucin, estaramos haciendo un diseo inflexible
(esttico), ya que el cliente no puede controlar cuando y como decorar el componente
con esa propiedad.

La solucin est en encapsular dentro de otro objeto, llamado Decorador, las nuevas
responsabilidades. El decorador redirige las peticiones al componente y, adems,
puede realizar acciones adicionales antes y despus de la redireccin. De este modo,
se pueden aadir decoradores con cualidades aadidas recursivamente.

>Aplicabilidad

Aadir objetos individuales de forma dinmica y transparente

Responsabilidades de un objeto pueden ser retiradas

Cuando la extensin mediante la herencia no es viable

Hay una necesidad de extender la funcionalidad de una clase, pero no hay razones
para extenderlo a travs de la herencia.

Existe la necesidad de extender dinmicamente la funcionalidad de un objeto y quizs

quitar la funcionalidad extendida.

>Participantes

Componente

Dene la interfaz para los objetos que pueden tener responsabilidades aadidas.

Componente Concreto

Dene un objeto al cual se le pueden agregar responsabilidades adicionales.

Decorador

Mantiene una referencia al componente asociado. Implementa la interfaz de la superclase

Componente delegando en el componente asociado.

Decorador Concreto

Aade responsabilidades al componente.

>Implementacion en JAVA
public abstract class Componente{
abstract public void operacion();
}
public class ComponenteConcreto extends Componente{
public void operacion(){
System.out.println("ComponenteConcreto.operacion()");
}
}
public abstract class Decorador extends Componente{
private Componente _componente;
public Decorador(Componente componente){
_componente = componente;
}
public void operacion(){
_componente.operacion();
}
}
public class DecoradorConcretoA extends Decorador{
private String _propiedadAadida;
public DecoradorConcretoA(Componente componente){
super(componente);
}
public void operacion(){
super.operacion();
_propiedadAadida = "Nueva propiedad";
System.out.println("DecoradorConcretoA.operacion()");
}
}
public class DecoradorConcretoB extends Decorador{
public DecoradorConcretoB(Componente componente){
super(componente);

}
public void operacion(){
super.operacion();
comportamientoAadido();
System.out.println("DecoradorConcretoB.operacion()");
}
public void comportamientoAadido(){
System.out.println("Comportamiento B aadido");
}
}
public class Cliente{
public static void main(String[] args){
ComponenteConcreto c = new ComponenteConcreto();
DecoradorConcretoA d1 = new DecoradorConcretoA(c);
DecoradorConcretoB d2 = new DecoradorConcretoB(d1);
d2.operacion();
}
}

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

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

>Ventajas e Inconvenientes

La principal ventaja del patrn fachada consiste en que para modificar las clases
de los subsistemas, slo hay que realizar cambios en la interfaz/fachada, y los
clientes pueden permanecer ajenos a ello. Adems, y como se mencion
anteriormente, los clientes no necesitan conocer las clases que hay tras dicha
interfaz.

Como inconveniente, si se considera el caso de que varios clientes necesiten

acceder a subconjuntos diferentes de la funcionalidad que provee el sistema,
podran acabar usando slo una pequea parte de la fachada, por lo que sera
conveniente utilizar varias fachadas ms especficas en lugar de una nica global.

Observer
Observador (en ingls: Observer) 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. Se trata de un patrn de
comportamiento (existen de 3 tipos: Creacin, Estructurales y de Comportamiento), es
decir, est relacionado con algoritmos de funcionamiento y asignacin
de responsabilidades a clases y objetos. Los patrones de comportamiento describen no
solamente estructuras de relacin entre objetos o clases sino tambin esquemas de
comunicacin entre ellos y se pueden clasificar en funcin de que trabajen
con clases (Mtodo Plantilla) u objetos (Cadena de Responsabilidad, Comando, Iterador,
Recuerdo, Observador, Estado, Estrategia, Visitante).
La variacin de la encapsulacin es la base de muchos patrones de comportamiento, por lo
que cuando un aspecto de un programa cambia frecuentemente, estos patrones definen un
objeto que encapsula dicho aspecto. Los patrones definen una clase abstracta que
describe la encapsulacin del objeto.
El patrn Observer es la clave del patrn de arquitectura Modelo Vista
Controlador (MVC). De hecho el patrn fue implementado por primera vez
en Smalltalk's MVC basado en un framework de interfaz. Este patrn est implementado
en numerosos libreras y sistemas, incluyendo todos los toolkits de GUI.

>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. Se trata de desacoplar la clase de los objetos
clientes del objeto, aumentando la modularidad del lenguaje, creando las
mnimas dependencias y evitando bucles de actualizacin (espera
activa o polling). 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
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.

>Implementacin en JAVA
Clase java.util.Observable
addObserver(o Observer)
deleteObserver(o Observer)
notifyObserver()
notifyObservers(Object data)
Interface java.util.Observer
void update (Observable o, Object data)

Strategy
El patrn Estrategia (Strategy) es un patrn de diseo para el desarrollo de software. Se
clasifica como patrn de comportamiento porque determina como se debe realizar el
intercambio de mensajes entre diferentes objetos para resolver una tarea. El patrn
estrategia permite mantener un conjunto de algoritmos de entre los cuales el objeto cliente
puede elegir aquel que le conviene e intercambiarlo dinmicamente segn sus
necesidades.

>Aplicabilidad
Cualquier programa que ofrezca un servicio o funcin determinada, que pueda ser
realizada de varias maneras, es candidato a utilizar el patrn estrategia. Puede
haber cualquier nmero de estrategias y cualquiera de ellas podr ser
intercambiada por otra en cualquier momento, incluso en tiempo de ejecucin. Si
muchas clases relacionadas se diferencian nicamente por su comportamiento, se
crea una superclase que almacene el comportamiento comn y que har de
interfaz hacia las clases concretas.
Si un algoritmo utiliza informacin que no deberan conocer los clientes, la
utilizacin del patrn estrategia evita la exposicin de dichas estructuras. Aplicando
el patrn a una clase que defina mltiples comportamientos mediante instrucciones
condicionales, se evita emplear estas instrucciones, moviendo el cdigo a clases
independientes donde se almacenar cada estrategia.

>Participantes
Contexto (Context) : Es el elemento que usa los algoritmos, por tanto, delega en la
jerarqua de estrategias. Configura una estrategia concreta mediante una
referencia a la estrategia necesaria. Puede definir una interfaz que permita a la
estrategia el acceso a sus datos en caso de que fuese necesario el intercambio de
informacin entre el contexto y la estrategia. En caso de no definir dicha interfaz, el
contexto podra pasarse a s mismo a la estrategia como parmetro.
Estrategia (Strategy): Declara una interfaz comn para todos los algoritmos
soportados. Esta interfaz ser usada por el contexto para invocar a la estrategia
concreta.
EstrategiaConcreta (ConcreteStrategy): Implementa el algoritmo utilizando la
interfaz definida por la estrategia.

>Consecuencias
La herencia puede ayudar a factorizar las partes comunes de las familias de
algoritmos (sustituyendo el uso de bloques de instrucciones condicionales). En este
contexto es comn la aparicin conjunta de otros patrones como el patrn plantilla.
El uso del patrn proporciona una alternativa a la extensin de contextos, ya que
puede realizarse un cambio dinmico de estrategia.
Los clientes deben conocer las diferentes estrategias y debe comprender las
posibilidades que ofrecen.
Como contrapartida, aumenta el nmero de objetos creados, por lo que se produce
una penalizacin en la comunicacin entre estrategia y contexto (hay una
indireccin adicional).

>Estructura

>Implementacin
public abstract class EstrategiaDibujo extends JFrame {
private float[] _x,_y;
private Color _c;
private int _ancho,_alto;
public EstrategiaDibujo() {
....
}
public abstract void dibujar(float[] px, float[] py);
}

Referencias
http://es.wikipedia.org/wiki/Abstract_Factory
http://es.wikipedia.org/wiki/Singleton
http://es.wikipedia.org/wiki/Adapter_(patr%C3%B3n_de_dise%C3%B1o)
http://es.wikipedia.org/wiki/Decorator_(patr%C3%B3n_de_dise%C3%B1o)
http://es.wikipedia.org/wiki/Facade_(patr%C3%B3n_de_dise%C3%B1o)
http://es.wikipedia.org/wiki/Observer_(patr%C3%B3n_de_dise%C3%B1o)
http://es.wikipedia.org/wiki/Strategy_(patr%C3%B3n_de_dise%C3%B1o)

Instituto Tecnolgico de Culiacn

Dpto. de Sistemas y Computacin
Tarea:
Investigacin de Patrones de Diseo

Asignatura:
Ingeniera de Software

Maestro Titular:
Martha Estela Valenzuela Tirado

Hora:
09:00-10:00

Elaborado por:
Sandoval Morales Jess Ivn
Fecha de Entrega:
28/03/14