Patrones de Diseño en Java

5/12/2018 Patrones de Diseño en Java - slidepdf.com

http://slidepdf.com/reader/full/patrones-de-diseno-en-java 1/39

Patrones De Diseño

en Java.

C h á v e z L ó p e z D a v i d

0 6 0 1 0 0 6 4

I n g e n i e r í a e n S i s t e m a s

C o m p u t a c i o n a l e s

0 1 / 1 2 / 2 0 1 1

Catedrático:

Ana María Chávez Trejo

Asignatura:

Estilos y Arq. De Software.

IV Unidad



1

Patrones de diseño en Java.

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en eldesarrollo 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 reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en

distintas circunstancias

Objetivos de los Patrones.

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

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Software



2

Patrones de Diseño en Java de tipo: Estructural.

Patrón de Diseño Adapter

Objetivo

Una clase Adapter implementa una interfaz que conoce a sus clientes y proporciona

acceso a una instancia de una clase que no conoce a sus clientes, es decir convierte la interfaz de

una clase en una interfaz que el cliente espera. Un objeto Adapter proporciona la funcionalidad

prometida por un interfaz sin tener que conocer qué clase se utiliza para implementar esa

interfaz. Permite trabajar juntas a dos clases con interfaces incompatibles.

Aplicación

Es útil el patrón adaptador cuando:

Se desea utilizar una clase existente, y su interfaz no coincide con la que es requerida para

la solución.

Se desea crear una clase reutilizable que coopera con clases no relacionadas o

imprevistas, es decir, las clases que no tienen necesariamente interfaces compatibles

Un adaptador de objeto se adapta a la interfaz de subclase padre.

Estructura

A continuación se muestra la estructura bajo la cual se rige el patrón de diseño, así como

sus participantes.



3

Participantes

Target

Define la interfaz específica del dominio que el cliente usa

Cliente (SimpleAdapter)

Colabora con los objetos para cumplir con la interfaz de Target

Adaptado

Define una interfaz existente que ayuda a la adaptación

Adapter

Adapta la interfaz del Adaptee a la interfaz de Target

Consecuencias

Los adaptadores clase y objeto tienen diferentes ventajas y desventajas.

Un adaptador de clase:

Adapta el Adaptee al Destino comprometiéndose con una clase Adaptado en concreto. El

adaptador permite reemplazar algunos de los comportamientos Adaptee, ya que este adaptador

es una subclase.

n adaptador de objeto:

Permite a un solo Adaptador trabajar con muchos Adaptadores, es decir, el propio

Adaptee y todas sus subclases. En consecuencia a lo mencionado con anterioridad se destacar los

siguientes puntos importantes:

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

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

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

Se utiliza una clase Adapter para determinar cuál de los métodos es de un objeto llama

otro objeto.



4

Es importante destacar que el patrón sea útil en otras situaciones considerando

determinadas funciones por ejemplo:

La cantidad de trabajo que el adaptador realiza depende de la similitud de la interfaz de

destino con los Adaptadores. Con la construcción de la adaptación de interfaz en una clase, se

elimina la suposición de que otras clases vean la misma interfaz, la adaptación de interfaz permite

incorporar una clase dentro de sistemas existentes que espera diferentes interfaces de la clase.

Patrones con los que se relaciona.

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

la misma interaz que el objeto por el que se sustituye.

Strategy

El patrón Strategy es estructuralmente similar al patrón Adapter. La diferencia está 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 interfaz particular. El patrón Strategy

proporciona objetos que implementan un interfaz particular con el propósito de alterar o

determinar el comportamiento de un objeto cliente.



5

Ejemplo de implementación del patrón.

Vamos a plantear el siguiente escenario: nuestro código tiene una clase Persona (la llamamos

PersonaVieja) que se utiliza a lo largo de todo el código y hemos importado un API que también

necesita trabajar con una clase Persona (la llamamos PersonaNueva), que si bien son bastante

similares tienen ciertas diferencias:

Nosotros trabajamos con los atributos nombre, apellido y fecha de nacimiento.

Sin embargo, la PersonaNueva tiene un solo atributo nombre (que es el nombre y apellido de la

persona en cuestión) y la edad actual, en vez de la fecha de nacimiento.

Para esta situación lo ideal es utilizar el Adapter. Para ello primero crearemos las 2 clases de

Persona y sus correspondientes interfaces.



6



7

Y ahora se crea el Adapter.



8

Y se utiliza de esta ultima manera.



9

Patrón de Diseño Facade.

Objetivo

Simplifica los accesos a un conjunto de objetos relacionados proporcionando un objeto

que todos los objetos fuera del conjunto utilizan para comunicarse con el conjunto. Define una

interfaz de más alto nivel que permite usar el sistema más fácil..

Aplicación

Se usa el patrón Facade cuando:

Se pretende proveer una interfaz única para un subsistema complejo. Esto ayuda a que un

subsistema sea más reutilizable y fácil de adaptar.

Existen gran número de dependencias entre clientes y clases que implementan una

abstracción. Con el patrón Facade se desacopla el cliente del subsistema, así como entre

subsistemas; esto promueve subsistemas independientes y portables.

Se quiere dividir en capas su subsistema. Usar Facade para definir el punto de entrada a

cada nivel del subsistema.

Estructura

En la figura se muestra la estructura bajo la cual se rige el patrón de diseño, asi como sus

participantes.



10

Participantes

Facade: Conoce que clases son responsables de una petición. Delega las peticiones del

cliente a objetos del subsistema apropiados.

Subsystem classes: implementa la funcionalidad del subsistema, maneja el trabajo

asignado por facade. Desconocen a facade, lo que indica que no tienen referencia a este.

Colaboración

El cliente se comunica con el subsistema transmitiendo peticiones a facade, que se

encarga, luego, de enviarlas a los objetos apropiados. Facade también puede realizar algún

trabajo, debido a la traducción de su interface a la interface que el subsistema posee.

El cliente que utiliza facade no tiene acceso al subsistema directamente.

Consecuencias

Facade ofrece las siguientes ventajas:

Protege al cliente de los componentes del subsistema, así reduce el número de objetos

con los que el cliente se relaciona. Con ello se hace menos tedioso de usar al subsistema.

Promueve un acoplamiento entre el cliente y el subsistema. Lo que permite modificar

componentes en el subsistema sin modificar el cliente.

No evita que se use clases del subsistema si la aplicación la necesita.

Colaboración

De forma general el cliente se comunica con el subsistema transmitiendo peticiones a

Facade, que se encarga, luego, de enviarlas a los objetos apropiados. También puede realizar

algún trabajo, debido a la traducción de su interface a la interface que el subsistema posee. El

cliente que no tiene acceso al subsistema directamente.



11

Usos Conocidos.

El sistema compilador de smalltalk utiliza facade para agrupar clase como escáner, flujos

de datos y analizador de sintaxis.

También es utilizado para agrupar frameworks.

En java las clases graphics y Font utilizan facade.

Patrones con lo que se relaciona

Abstract Factory

Se utiliza Facade, para facilitar el acceso a las familias de objetos.

Mediator

Similar a Facade, pues este también abstrae la funcionalidad de clases existentes.

Mediator intenta abstraer la comunicación, entre una colección de objetos, así como sus

comportamientos adicionales. La interfaz Facade se implementa como un Singleton para

garantizar un punto de acceso único al subsistema.

Implementación del patrón

Es útil considerar los siguientes aspectos cuando se utiliza Facade:

Reducir el acoplamiento entre un cliente y el subsistema. El acoplamiento se reduce

incluso cuando Facade no es una interfaz sino una clase abstracta,

Un subsistema encapsula clases haciéndolas privadas; el uso de clases privadas restringe

el acceso del cliente al subsistema directamente.



12

Aquí un ejemplo de la utilización del Patrón de diseño Facade.

import java.util.Calendar;import java.util.Formatter;

import java.util.GregorianCalendar;

/** Fachada */public class FormatoFecha {

private GregorianCalendar gcal;

public FormatoFecha(String isodate_ymd) {String[] a = isodate_ymd.split("-");gcal = new GregorianCalendar(Integer.parseInt(a[0]),

Integer.parseInt(a[1])-1, Integer.parseInt(a[2]));}

public void sumarDias(int dias) {gcal.add(Calendar.DAY_OF_MONTH, dias);

}

public String toString() {return String.format("%1$tY-%1$tm-%1$td", gcal);

}}

Clase Cliente.

/** Cliente */public class Cliente {

public static void main(String[] args) {FormatoFecha d = new FormatoFecha("2011-05-15");

System.out.println("Fecha: "+d);d.sumarDias(15);System.out.println("15 días después: "+d);

}}



13

Patrón de Diseño Composite

Objetivo

Es útil en la construcción de objetos complejos por medio de la composición recursiva de

objetos similares. Dicho patrón también permite que los objetos del árbol se manipulen por un

manejador consistente, para requerir todos los objetos hay una superclase o una interfaz común.

Asimismo compone objetos en estructura de árbol y los representa en jerarquías Todo- Parte. Dej

a los usuarios manejar objetos simples y compuestos uniformemente.

Motivación

Los editores gráficos permiten a los usuarios trabajar con diagramas simples y

compuestos. Los usuarios crean grupos compuestos a partir de una lista de componentes, que se

agrupan para formar componentes mayores. Una simple implementación sería un grupo de clases

que definen gráficas primitivas tales como texto y líneas, y otras clases diferentes actúan como

contenedoras de estas primitivas; pero trabajar de esta manera genera un problema; un código

que use estas clase trabaja con objetos primitivos y compuestos por separado, aún si la mayoría

de veces las trata idénticamente. Esta distinción hace más complejo el sistema, el patrón de

diseño Composite ofrece una forma de manejar objetos compuestos sin que el usuario tenga que

hacer la distinción.

La clave del patrón Composite es una clase abstracta, que es la clase padre tanto de

objetos simples, como de compuestos. Esta clase incluye métodos para objetos simples y también

para los compuestos.

Las clases primitivas (simples) no implementaran los métodos de la clase abstracta que

actúan sobre los componentes de un objeto (porque son objetos simples); por su lado las clases

contenedoras (compuestas), sí trabajan todos los métodos.

En el patrón los objetos individuales (simples), son las hojas de un árbol, y los compuestos

son nodos que contienen las hojas que se derivan de ellos

.



14

Aplicabilidad

Los clientes no conocen la diferencia entre los objetos individuales y los grupos de objetos

compuestos, a fin de que los trate de forma genérica.

Se cuenta con un objeto complejo que se necesita descomponer en una jerarquía de

objetos que forman parte de todo

Se minimiza la complejidad de las jerarquías minimizando el número de objetos hijos

diferentes en el árbol que los objetos compuestos necesitan para formarse.

Se desea representar jerarquías homogéneas de los objetos.

Se desea que los clientes podrán hacer caso omiso de la diferencia entre las

composiciones de objetos e individuales.Los clientes tratan todos los objetos de la

estructura compuesta de manera uniforme.

Estructura

A continuación se muestra la estructura bajo la cual se rige el patrón de diseño, asi como

sus participantes.



15

Participantes

Component:

Determina la interfaz para la presentación de los objetos de la composición, así como el

manejo de los componentes hijo, establece algunos comportamientos predefinidos para todas las

clases según su correspondencia.

Leaf:

Define la conducta de los objetos primitivos, otra de sus características es no tener hijos

además de aclarar el comportamiento explícito de cada objeto simple.

Composite:

Detalla el comportamiento de los objetos participantes que tienen los hijos, acumula a los

hijos e implementa las operaciones de los componentes.

Client:

Emplea los objetos por medio de la interfaz proporcionada Component.

Consecuencias

Define las jerarquías de clase que consiste en objetos primitivos y objetos compuestos. Los

objetos simples se descomponen en objetos complejos que a su vez están compuestos, y

así recursivamente.

Cuando el código cliente espera un objeto primitivo, puede tomar también un objeto

compuesto.

Hace que el cliente pueda tratar las estructuras de objetos compuestos e individuales de

manera uniforme. Los clientes normalmente se están tratando con una hoja o un objeto

compuesto. Esto simplifica el código de cliente, ya que evita tener que escribir en

etiquetas y funciones en las clases que definen la composición.

Hace que sea más fácil agregar nuevos tipos de componentes, que define las hojas de

trabajo, compuestos o subclases automáticamente con las estructuras existentes y el



16

código de cliente. Los clientes no tienen que combinarse por nuevos componente de las

clases.

Colaboraciones

Los clientes utilizan la interfaz de componentes para interactuar con objetos en la

estructura de materia compuesto. Si el receptor es una hoja, la solicitud se maneja directamente.

Si el destinatario es un compuesto, por lo general reenvía las solicitudes a los

componentes de su hijo, posiblemente, realiza operaciones adicionales antes o después de la

expedición. Los clientes utilizan la interfaz de clase para que los componentes interactúen con

los objetos.

Patrones con los que se relaciona.

Chain of Responsibility

El patrón Chain of Resposibility se combinacon el patrón Composite para añadir enlaces

del hijo al padre (para propagar responsabilidades hacia arriba), de tal forma que, los hijos

consigan la información sobre un progenitor sin tener que conocer qué progenitor proporciona la

información.

Decorator

Generalmente se usan juntos.

Flyweight

Para compartir componentes, cuando no haya referencias a los padres.

Iterator

Para recorrer los hijos en un Composite.

Visitor

Es util el patrón Visitor para encapsular operaciones en una clase simple, que de lo

contrario podría propagarse a través de muchas clases y agregar comportamiento a las clases del

patrón Composite.

Implementación del patrón

Se consideran muchas situaciones cuando se implementa el patrón Composite:



17

Referencias explícitas a los padres. Si las clases que participan en el patrón Composite

implementan alguna operación por delegación de estas a sus objetos padre, entonces el

mejor modo para observar velocidad y simplicidad es teniendo en cada instancia del

Componente Abstracto una referencia a su padre.

Compartir componentes. Es importante implementar el puntero al padre de una forma

que se asegure la consistencia entre padre e hijo.

Siempre un Componente Abstracto identifique a un Composite Abstracto como su padre,

si y sólo si, el Composite Abstracto lo identifica como uno de sus hijos.

Declarar las operaciones de manejo de hijos. La forma de obligar esto es modificar las

referencias al padre y al hijo solamente en la clase Composite Abstracto añadiendo y

quitando métodos.

El lugar habitual para definir la referencia de los padres está en la clase de componentes.Las clases compuestas heredan la referencia y las operaciones que se gestionan.

Ejemplo de Aplicación del Patrón Composite.

El patrón Composite da una solución elegante a este problema, de la que además resulta en una

implementación más sencilla.

A la clase Figura la llamaríamos Gráfico y de ella extenderían tanto Círculo, Cuadrado y Triángulo,

como GrupoDeImágenes. Además, ésta última tendría una relación todo-parte de multiplicidad *

con Gráfico: un GrupoDeImágenes contendría varios Gráficos, ya fuesen éstos Cuadrados,

Triángulos, u otras clases GrupoDeImágenes.

Así, es posible definir a un grupo de imágenes recursivamente. Por ejemplo, un objeto cuya clase

es GrupoDeImágenes podría contener un Cuadrado, un Triángulo y otro GrupoDeImágenes, este

grupo de imágenes podría contener un Círculo y un Cuadrado. Posteriormente, a este último

grupo se le podría añadir otro GrupoDeImágenes, generando una estructura de composición

recursiva en árbol, por medio de muy poca codificación y un diagrama sencillo y claro.

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o



18

Diagrama UML

Clase Componente.

import java.util.*;

public abstract class Componente{

protected String nombre;public Componente (String nombre){

this.nombre = nombre;}abstract public void Agregar(Componente c);abstract public void Eliminar(Componente c);abstract public void Mostrar(int profundidad);

}



19

Clase Compuestoclass Compuesto extends Componente{

private ArrayList<Componente> hijo = new ArrayList<Componente>();public Compuesto (String name){

super(name);}@Overridepublic void Agregar(Componente componente){

hijo.add(componente);}@Overridepublic void Eliminar(Componente componente){

hijo.remove(componente);}@Override

public void Mostrar(int profundidad){

System.out.println(nombre + " nivel: " + profundidad);for (int i = 0; i < hijo.size(); i++)

hijo.get(i).Mostrar(profundidad + 1);}

}

Clase Hojaclass Hoja extends Componente{

public Hoja (String nombre){

super(nombre);}public void Agregar(Componente c){

System.out.println("no se puede agregar la hoja");}public void Eliminar(Componente c){

System.out.println("no se puede quitar la hoja");}public void Mostrar(int depth){

System.out.println('-' + "" + nombre);}

}



20

Clase Clientepublic class Client{

public static void main(String[] args){

Compuesto raiz = new Compuesto("root");raiz.Agregar(new Hoja("hoja A"));raiz.Agregar(new Hoja("hoja B"));Compuesto comp = new Compuesto("compuesto X");comp.Agregar(new Hoja("hoja XA"));comp.Agregar(new Hoja("hoja XB"));raiz.Agregar(comp);raiz.Agregar(new Hoja("hoja C"));Hoja l = new Hoja("hoja D");raiz.Agregar(l);raiz.Eliminar(l);raiz.Mostrar(1);

}

}



21

Patrón de Diseño Bridge

Intención u objetivo

Es útil cuando hay una jerarquía de abstracciones y la correspondiente jerarquía de

implementaciones. Más que combinar las abstracciones e implementaciones en muchas clases

distintas, el patrón Bridge implementa las abstracciones e implementaciones como clases

independientes para ser combinados dinámicamente. Es decir, desacopla una abstracción de su

implementación y les permite variar independientemente.

Aplicación

Utilizar el patrón Bridge cuando:

Se quiere evitar la vinculación entre la abstracción y la implementación .Esto es debido a

que la implementación es seleccionada o cambiada en tiempo de ejecución.

La abstracción e implementación tienen que ser extendibles por las subclases.

Un Bridge permite ampliar de forma independiente las abstracciones e implemetaciones

esto no causa ningún efecto de la aplicación con esto se evita que los clientes no noten los

multiples objetos en la implementación.

Estructura

A continuación en la figura se muestra la estructura bajo la cual se rige el patrón de

diseño, así como sus participantes.



22

Los Participantes :

Abstraction:

Define la abstracción de la interfaz, manteniedo una referencia a un objeto que

implementa la interfaz.

RefinedAbstraction:

Amplía la interfaz definida por la abstracción, de modo que captura las especificaciones o

información necesaria proveniente del objeto que implementa la interfaz.

Implementor:

Define la interfaz de la aplicación clases. Esta interfaz no tiene que corresponder

exactamente a la interfaz de abstracción, de hecho las dos interfaces pueden ser muy

diferentes. Normalmente la interfaz Implementor proporciona sólo operaciones

primitivas, y define la abstracción de alto nivel sobre la base de estas

operaciones primitivas.

ConcreteImplementor:

Implementa la interfaz concreta y define sus aplicació

Client:

Utiliza los objetos proporcianados por sus gusto.

Consecuencias

Separa la interfaz de la aplicación: las aplicaciones no están relacionadas siempre con la

interfaz. Dicha característica es muy útil cuando se garantiza la compatibilidad entre

diferentes bibliotecas de clases.

Se protege la implementación a los clientes y el mecanismo de acompañamiento.

Mejora la extensibilidad, para de esta forma ampliar la abstracción y ejecución de

jerarquías independientes.



23

Colaboraciones

La abstracción envía las peticiones del cliente a su objeto Implementor.

Patrones con los que se Relaciona

Abstract Factory

Crear y configurar un bridge en particular.

Adapter

Tiene una estructura similar pero su intención es diferente. El patrón bridge separa la

abstracción de la implementación de un componente, permitiendo que sean modificados

independientemente, mientras adapter reutiliza un componente ya existente que no es

compatible.

Implementación del patrón.

En el siguiente ejemplo, se lleva a cavo la solicitud de un pedido en una panadería, donde el

cliente elige el diferente tipo de pan que hay disponible.

//nuestra clase Abstraction, su método permite obtener el tipo de pan del pedido//

package Logica;

public abstract class Panaderia {

public abstract TipoDePan getImplementador();

public abstract String nombrePan();

}

//*Ahora creamos una clase que hereda de Panaderia, en la cual se estructura el metodo de la

clase abstracta y se crean nuevos metodos, los cuales trabajan con un objeto de la que

implementa la interfaz*//



24

package Logica;

public class Panes extends Panaderia {

private TipoDePan pan;

public String nombrePan() {

return pan.tipoPan();

}public void setInterfaz(TipoDePan tipoInterfaz) {

pan = tipoInterfaz;

}

public TipoDePan getImplementador() {

return pan;

}

}

// Creamos la interfaz//

package Logica;

public interface TipoDePan {

public abstract String tipoPan();

}

//*Ahora se crean las clases de los diferentes tipos de pan disponibles sobreescribiendo el método implementado de lainterfaz*//

package Logica;

public class PanDeFrutas implements TipoDePan {

public String tipoPan() {

return "Pan de Frutas";

}

}

package Logica;

public class PanIntegral implements TipoDePan {


return "Pan integral";

}

}

package Logica;

public class PanLight implements TipoDePan {


return "Pan Light";

}

}

Por último tenemos la vantana donde el cliente podra seleccionar y obtener su pedido:

package Interfaz;

import Logica.*;

import java.awt.event.ActionEvent;

import java.awt.event.ActionListener;import javax.swing.JButton;

import javax.swing.JFrame;

import javax.swing.JLabel;

public class Pedido extends JFrame implements ActionListener {

//atributos de la clase//

Panaderia panaderia ;

private JButton panIntegral;

private JButton panLight;

private JButton panDeFrutas;



25

private JLabel suOrden;

//constructor de la clase, e inicializamos y ubicamos los atributos//

public Pedido(){

this.setSize(400,300);

this.setLayout(null);

this.setDefaultCloseOperation(Pedido.DISPOSE_ON_CLOSE);

this.setTitle(":::Panaderia:::");

suOrden = new JLabel();

suOrden.setSize(300,100);

suOrden.setLocation(30, 20);

suOrden.setText("Seleccione su Pan :");

this.getContentPane().add(suOrden);

panIntegral = new JButton();

panIntegral.setSize(110, 30);

panIntegral.setLocation(10, 100);

panIntegral.setText("pan Integral");

this.getContentPane().add(panIntegral);

panIntegral.addActionListener(this);panLight = new JButton();

panLight.setSize(110, 30);

panLight.setLocation(130, 100);

panLight.setText("pan Light");

this.getContentPane().add(panLight);

panLight.addActionListener(this);

panDeFrutas = new JButton();

panDeFrutas.setSize(120, 30);

panDeFrutas.setLocation(250, 100);

panDeFrutas.setText("pan De Frutas");

this.getContentPane().add(panDeFrutas);

panDeFrutas.addActionListener(this);

}

//manupula el objeto segun la especificacion del cliente//

@Override

public void actionPerformed(ActionEvent e) {

//inicializa un objeto de la clase Panes//

Panes pan= new Panes();

if (e.getSource() == panDeFrutas) {

//reliza la implemntacion pasando en su método el t ipo de pan que se eligió//

pan.setInterfaz(new PanDeFrutas());

}

if (e.getSource() == panLight) {

pan.setInterfaz(new PanLight());}

if (e.getSource() == panIntegral) {

pan.setInterfaz(new PanIntegral());

}

//se presenta al cliente el pedido como tal//

suOrden.setLocation(100, 130);

suOrden.setText("Su orden es : " + pan.nombrePan());

}

}



26

Patrón de Diseño Proxy

Objetivo

Es un patrón muy general que ocurre en muchos otros patrones, pero nunca él mismo en

su puro estado. El patrón Proxy hace llamadas a métodos de un objeto que ocurre indirectamente

a través de un objeto proxy que actúa como un sustituto para otro objeto, delegando las llamadas

a métodos a ese objeto. Las clases para los objetos proxy se declara de una forma que

normalmente eliminan el conocimiento de los objetos del cliente que se tratan con un proxy. Es

decir, este patrón provee un representante de acceso a otro objeto.

Aplicación

Es útil cuando se hace una referencia versátil a un objeto. Existen varias situaciones

comunes en las que se aplica el patron Proxy por ejemplo:

Para representar un objeto local.

Para objetos pesados por demanda.

Control de entrada a un objeto.

Para sustituir un punto basico de acceso en la realización de cambios para acceder al

objeto.



27

Estructura

Aquí se muestra la estructura bajo la cual se rige el patrón de diseño, así como sus participantes.

Participantes

Proxy:

Tiene una referencia que permite al Proxy acceder el objeto, proporciona la interfaz

similar a la del sujeto, de forma que un Proxy que puede llegar a ser sustituido. Además de

mantener la referencia al objeto RealSubject , tiene una interfaz idéntica a la de Subject así un

proxy puede sustituirse por un RealSubject, y controla el acceso al RealSubject y puede ser el

responsable de su creación y borrado.

Subject:

Delimita la interfaz común para el RealSubject y Proxy de tal forma que tenga la posibilidad

de utilizar un Proxy en cualquier sitio en el que se espere un RealSubject.

RealSubject:

Define el objeto real que Proxy representa.



28

Client:

Quien desea acceder al objeto.

Consecuencias

El patrón Proxy introduce un nivel de indireccion al acceder a un objeto. La dirección

adicional tiene muchos usos, dependiendo del tipo de Proxy:

Un proxy remoto oculta el hecho de que un objeto se encuentra en un espacio de

direcciones diferentes.

Un proxy virtual realiza optimizaciones como la creación de un objeto bajo demanda.

Tanto las delegaciones de protección y las referencias inteligentes permiten más tareas de

mantenimiento cuando un objeto es acceder a ella.

Colaboraciones

Proxy reenvía las solicitudes del sujeto real, cuando proceda, en función del tipo de Proxy.

Patrones relacionados

Un Proxy no tiene que conocer el tipo de un sujeto real y puede acceder a él a través de

la interfaz abstracta. Se pueden utilizar facilidades de los lenguajes para implementarlo.

Bridge

Un Proxy sólo tiene una implementación, y un Bridge puede tener más de una. Proxy se

suele usar para controlar el acceso a su implementación, el Bridge permite cambiar una

implementación dinámicamente.

Adapter

Proporciona una interfaz diferente al objeto que adapta, pero el Proxy tiene la misma

interfaz Aunque el Proxy puede reutilizar una operación (así su interfaz puede verse como un

subconjunto).

Decorador

Se puede implementar de manera similar al Proxy pero el propósito es diferente: el

public interface Soporte {

public void escribir( String mensaje );



29

public String leer( int numLinea );

public Vector leer();

}

Decorador añade responsabilidades a un objeto, el Proxy sólo controla su acceso.

Ejemplo:

Tenemos un interface para escribir y leer de un soporte:

Además tenemos una clase, denominada Pizarra, que implementa el interface Soporte y que en su

método escribir(String mensaje) simplemente añade el argumento a un Vector. El método leer(int

numLinea) devuelve la cadena cuyo orden dentro del vector es el argumento. El cliente (main)

pueda insertar (escribir) y obtener (leer) cadenas.

import java.util.*;

public class Pizarra implements Soporte {

private Vector mensajes = new Vector();

public void escribir(String mensaje) {

mensajes.add(mensaje);

}

public String leer(int numLinea) {

return mensajes.get(numLinea);

}

public Vector leer() {

return mensajes;

}

}

El proxy es un intermediario (que también implementa el interface del objeto real) y que nos

permite añadir o modificar comportamiento sin reescribir el objeto real. En escribir() del proxy

añado el número de línea y delega en la Pizarra el resto de comportamiento. Es interesante

observar que este patrón evita abusar del uso de herencia. Este abuso es la primera tentación del

novato, ya que piensa: "si quiero modificar el comportamiento de una clase hago el nuevocomportamiento en una clase hija". No es que la herencia sea de partida ilegal o inconveniente,

simplemente se trata de no abusar de ella aplicandola a todo tipo de problema. De esta forma no

caeremos en el vicio de aquel que sólo sabía usar martillos y todos los problemas le parecían

clavos.



30

import java.util.Vector;

public class ProxyDePizarra implements Soporte {

private Soporte soporte;

public ProxyDePizarra() {

this.soporte = new Pizarra();

}

public ProxyDePizarra( Soporte soporte) {

this.soporte = soporte;

}

public void escribir( String mensaje ) {

String linea = String.valueOf(soporte.leer().size()+1) + " " + mensaje;

soporte.escribir( linea );

}

public String leer( int numLinea ) {

return soporte.leer( numLinea );}

public Vector leer() {

return soporte.leer();

}

}

Un aspecto importante del cliente es que sólo utiliza el tipo Interface Soporte para acceder al

proxy, con lo que conseguimos generalidad:

public class Inicio {static public void main(String[] args) {

try {

//// Creamos el proxy

Soporte proxy = Factoria.getPizarra("ProxyDePizarra");

//// Escribimos (el proxy inserta número de línea)

proxy.escribir("En un lugar de La Mancha");

proxy.escribir("de cuyo nombre no quiero acordarme");

for (String str : proxy.leer())

Visor.mostrar(str);

} catch (Exception e) {

e.printStackTrace();

}

}

}

La factoria simple es otro patrón importante. Una factoría se centra en ocultar la instanciación de

una clase. En nuestro caso anterior devuelve un objeto del tipo ProxyDePizarra:



31

/*******************************************************************************

*****

* Factoria de pizarra (objeto real o proxy). Recibe el nombre de la clase

* (sin especificar paquete) y crea y devuelve el objeto (real o proxy).

********************************************************************************

***/

public class Factoria {

static public Soporte getPizarra( String nomClase ) throws Exception {

Class clase = Class.forName( Factoria.class.getPackage().getName() + "." +

nomClase);

return (Soporte) clase.newInstance();

}

}

Nota: Para que el newInstance() de la Factoria pueda funcionar debe existir un constructor sin

argumentos en el ProxyDePizarra. El visor es algo elemental, tan sólo sirve para diferenciar elmodelo de la vista:

public class Visor {

static public void mostrar( String mensaje ) {

System.out.println( mensaje );

}

}

El resultado final sería:

1 En un lugar de La Mancha

2 de cuyo nombre no quiero acordarme



32

Otras características

El proxy y el objeto real comparten interface. El proxy debe tener una referencia al objeto real.

Ya hemos dicho que el proxy es un intermediario que implica un recubrimiento del objeto real

para añadir o modificar comportamiento. Especialmente apropiado cuando estamos en

situaciones en las que tenemos que elegir entre las operaciones del objeto real y las del proxy.

Aunque en el ejemplo anterior no hacemos instancia del objeto real ni permitimos ningún acceso

directo a él, podriamos tener dos tipos de acceso: uno directo al objeto real y otro al proxy.

Soporte piz = Factoria.getPizarra("Pizarra");Soporte proxy = new ProxyDePizarra(piz);

piz.escribir("XYZ"); // NO añade nº de línea

proxy.escribir("QQQ"); // SI añade nº de línea



33

Patrón de Diseño Chain of Responsability

Intención u objetivo

Permite a un objeto enviar un comando sin conocer qué objeto u objetos lo recibirán,

evitando el acoplamiento entre el que envía y el que recibe una petición. Esto permite el paso del

comando a un objeto de la cadena que es parte de una gran estructura. Cada objeto de la cadena

podría manejar el comando, pasar el comando al siguiente objeto de la cadena, o las dos cosas.

Aplicación

Usar el patrón de la cadena de responsabilidad cuando:

Más de un objeto maneja una petición, y el controlador no se sabe Apriori. El

controlador se determina de forma automática.

Se desea remitir una petición a uno de varios objetos sin especificar el receptor de forma

explícita.

La cadena de la responsabilidad del conjunto de objetos que puede manejar una solicitud

se especifica de forma dinámica.

Estructura

Aquí se muestra la estructura bajo la cual se rige el patrón de diseño, asi como sus

participantes.



34

Una estructura de objetos típicos podría tener este aspecto:

Paticipantes

Cliente:

Es el encargado de generar las peticiones que pasaran por el Handler (manejador)

genérico.

Handler (Manejador):

Está compuesto por un interfaz donde se desarrollan las peticiones que genera el cliente.

ManejadorConcreto:

Manipula la petición que le corresponda del cliente.

Consecuencias

Cadena de Responsabilidad tiene los siguientes beneficios:

Reducción del acoplamiento

El patrón libera un objeto al saber que otro objeto controla una solicitud. Sólo un

objeto tiene que saber que atenderán las peticiones "de manera apropiada." Tanto el receptor

como el remitente no tienen conocimientos explícitos de cada uno, y un objeto en la cadena no

tiene por qué saber acerca de la estructura de la cadena. Como resultado, la

cadena de responsabilidad puede simplificar las interconexiones del objeto.

Mayor flexibilidad en la asignación de responsabilidades a los objetos



35

Agrega la flexibilidad en la distribución de responsabilidades entre los objetos.

Se agregan o cambian las responsabilidades para el manejo de una solicitud mediante la adición

de cualquier otro modo de cambiarse la cadena en tiempo de ejecución. Se combinan esto con

sus subclases de la especialización de controladores en forma estática.

La recepción no está garantizada

La solicitud puede no ser controlada cuando la cadena no este configurada correctamente.

Colaboraciones

Cuando un cliente emite una solicitud, ésta se propaga a lo largo de la cadena hasta

que un objeto Concrete Handler asume la responsabilidad de su manejo.

Patrones relacionados

Composite

Se relaciona con el ya que el patrón Chain of Responsability permite la relación entre el

padre y el hijo, sin que este sepa de qué progenitor está obteniendo la información.

Implementación.

Ejemplo:

public class ChainOfResponsabilityPattern {

public void main(String args[]){new A("C");

}

public abstract class Letter{String letter;abstract public void checkLetter();

}

public class A extends Letter{public A(String letter){

this.letter = letter;checkLetter();

}public void checkLetter() {

if(!letter.equals("A")){new B(letter);//Next Chain

}



36

else{System.out.print("Here we have " +

letter);}

}}

public class B extends Letter{public B(String letter){



if(!letter.equals("B")){new C(letter);//Next Chain

}else{System.out.print("Here we have " +

letter);}

}

}

public class C extends Letter{public C(String letter){



if(letter.equals("C")){System.out.print("Check with numbers

dude!!");}

}

}

El siguiente código java muestra un ejemplo de este patrón para una clase que hace un 'log'. Cada

elemento de log decide si debe de mostrar el log dependiendo de su nivel de log y pasa el mensaje

al siguiente elemento. La salida será:

Escribiendo en DEBUG: Entrando en function y.Escribiendo en DEBUG: Paso 1 completadoEscribiendo en STDERR: Paso 1 completado.

Escribiendo en DEBUG: Ha ocurrido un error.Enviando un e-mail: Ha ocurrido un error.Escribiendo en STDERR: Ha ocurrido un error.



37

Observese que una implementación 'pura' de este patrón detendría la cadena. En este ejemplo no

ocurre así.

También notar que si fuera un implementación 'pura', habría que cambiar el orden en la creación

del objeto Logger l , pues en este caso, nunca se llegaría a lanzar message de la clase StderrLogger ,

pues tiene un nivel menos importante (mask=5) que su predecesor EMailLogger (mask=3).

import java.util.*;

abstract class Logger {public static int ERR = 3;public static int NOTICE = 5;public static int DEBUG = 7;protected int mask;

protected Logger next; // el siguiente elemento en la cadenapublic Logger setNext(Logger l) { next = l; return this; }

abstract public void message(String msg, int priority);

}

//clase

class DebugLogger extends Logger{public DebugLogger(int mask) { this.mask = mask; }

public void message(String msg, int priority) {if (priority <= mask) System.out.println("Escribiendo en DEBUG: "

+ msg);if (next != null) next.message(msg, priority);

}}

class EMailLogger extends Logger{public EMailLogger(int mask) { this.mask = mask; }

public void message(String msg, int priority) {if (priority <= mask) System.out.println("Enviando un e-mail: " +

msg);if (next != null) next.message(msg, priority);

}}

//clase

class StderrLogger extends Logger{public StderrLogger(int mask) { this.mask = mask; }

public void message(String msg, int priority) {if (priority <= mask) System.out.println("Escribiendo en STDERR: "

+ msg);if (next != null) next.message(msg, priority);

}}



38

//Clase

class ChainOfResponsibilityExample{public static void main(String[] args) {

// Construimos la cadena// DebugLogger(DEBUG = 7) => EMailLogger(Error = 3) =>

StderrLogger(Notice = 5)Logger l = new DebugLogger(Logger.DEBUG).setNext(

new EMailLogger(Logger.ERR).setNext(new StderrLogger(Logger.NOTICE) ) );

// Ejecutamosl.message("Entrando en function y.", Logger.DEBUG); // manejado

por DebugLoggerl.message("paso 1 completado.", Logger.NOTICE); // manejado

por DebugLogger y StderrLoggerl.message("Ha ocurrido un error.", Logger.ERR); // menejado

por los tres Logger}

}

Patrones de Diseño en Java

Documents

Transcript of Patrones de Diseño en Java