AO DE LA INVERSIN PARA EL

DESARROLLO RURAL Y LA SEGURIDAD

ALIMENTARIA
FACULTAD DE INGENIERA,
ARQUITECTURA Y URBANISMO
TENDENCIAS ORGANIZACIONALES
CURSO:
INGENIERIA DE SOFTWARE II
ESCUELA:
INGENIERA DE SISTEMAS
INTEGRANTES:
CHUNGA ZULUETA JORGE LUIS
HUAMAN VILLANUEVA BRAYAN
LOPEZ YOVERA ARMANDO
ORTIZ MATUTE MEGAN ASHLEY
CICLO:
VI
DOCENTE:
DENY FUENTES

2014

Patrones de diseo orientados a objetos

I.

Fundamentos Bsicos

Conceptos:
a) Patrn: un patrn es una regla con tres partes que expresa la relacin
entre un determinado contexto, un problema y una solucin
b) Patrn de diseo: Provee un esquema para refinar los subsistemas o
componentes de un sistema de software.
stos se abocan a un elemento especfico del diseo, como un
agrupamiento de componentes, a fin de resolver algn problema de diseo,
relaciones entre los elementos de una pgina, o mecanismos para efectuar
la comunicacin entre componentes.

Aplicaciones en el Desarrollo del Software:

Adems de su aplicacin directa en la construccin de software en general, y
derivado precisamente del gran xito que han tenido, los patrones de diseo
han sido aplicados a mltiples mbitos concretos producindose "lenguajes de
patrones" y extensos "catlogos" de la mano de diversos autores.
En particular son notorios los esfuerzos en los siguientes mbitos:
a. Patrones de interfaces de usuario, esto es, aquellos que intentan definir las
mejores formas de construir interfaces hombre-mquina (vase Interaccin
persona-computador, Interfaz grfica de usuario).
b. Patrones para la construccin de sistemas empresariales, en donde se
requieren especiales esfuerzos en infraestructuras de software y un nivel de
abstraccin importante para maximizar factores como la escalabilidad o el
mantenimiento del sistema.
c. Patrones para la integracin de sistemas (vase Integracin de aplicaciones
empresariales), es decir, para la intercomunicacin y coordinacin de
sistemas heterogneos.
d. Patrones de flujos de trabajo, esto es para la definicin, construccin e
integracin de sistemas abstractos de gestin de flujos de trabajo y procesos
con sistemas empresariales. Vase tambin BPM.

II.

Objetivos de los Patrones de Diseo

Los patrones de diseo pretenden:
a) Proporcionar catlogos de elementos reusables en el diseo de
sistemas software.
b) Evitar la reiteracin en la bsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
c) Formalizar un vocabulario comn entre diseadores.
d) Estandarizar el modo en que se realiza el diseo.

e) Facilitar el aprendizaje de las nuevas generaciones de diseadores

condensando conocimiento ya existente.
Asimismo, no pretenden:
a) Imponer ciertas alternativas de diseo frente a otras.
b) Eliminar la creatividad inherente al proceso de diseo.
c) No es obligatorio utilizar los patrones, solo es aconsejable en el caso de
tener el mismo problema o similar que soluciona el patrn, 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".

III.

Estructuras de Patrones de Diseo

1. Nombre del patrn: sirve para ser reconocido entre diseadores. Estos hace
que sea ms fcil pensar en diseos y comunicarlas, sus ventajas y
desventajas.
2. Problema: describe cuando aplicar el patrn. En l se explica el problema y su
contexto.
Podra describir los problemas especficos de diseo, como la forma para
representar algoritmos como objetos. Se podra describir la clase o la
estructura del objeto que son sintomticos de un diseo inflexible.
A veces el problema incluye una lista de condiciones que deben cumplirse
antes de que se aplique el patrn de diseo.
3. Solucin: Describe los elementos que componen el diseo, sus relaciones,
responsabilidades,
y
colaboraciones.
La solucin no describe un diseo particular y concreto o implementacin,
debido a que un patrn es una plantilla que puede ser aplicado en muchas
situaciones diferentes. En lugar de ello el patrn proporciona una descripcin
abstracta de un problema de diseo y como una disposicin general de
elementos (clases y objetos) resuelve ella.
4. Consecuencias: son los resultados y compromisos de aplicar el patrn.
Aunque las consecuencias son a menudo desapercibidas cuando escribimos
las decisiones de diseo, que son fundamentales para la evaluacin de
alternativa de diseo y para la comprensin de costos y los beneficios y aplicar
el patrn. Las consecuencias en el software suelen ser referidos a menudos,
tiempo y espacio.
Pueden referirse tambin al lenguaje y a la cuestin de la aplicacin, dado que
la reutilizacin es a menudo un factor orientado a objetos de diseo, las
consecuencias de un patrn incluyen su impacto en la flexibilidad,
extensibilidad o la portabilidad de un sistema. El tener un estado de
consecuencias ayuda a entender la forma explcita de los patrones y
evaluarlos.
IV. Categoras de Patrones de Diseo
En la siguiente imagen podremos ver las categoras de patrones de diseo y la
clasificacin de estas considerando si estas estn enfocadas a clases u
objetos.

5.1.

Patrones de diseo de creacin:

Los patrones de diseo de creacin permiten que el sistema sea independiente
de cmo se crean, componen o representan sus objetos. Para si poder crear
sistemas ms dependientes de la composicin de objetos que de la herencia
de clases, se trata de que el comportamiento se defina ms por la composicin
de un conjunto pequeo de comportamientos fundamentales que por la
definicin mediante herencia de todos los comportamientos posibles. Por tanto,
la creacin de objetos es algo ms que instanciar una clase.
5.1.2. Abstract Factory (fabrica Abstracta)
Es un patrn creacional que intenta solucionar problemas como: la creacin de
diferentes familias de objetos relacionados o que dependen entre s, sin
especificar sus clases concretas. 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.
Se aplica principalmente a objetos. Tratan con las relaciones entre objetos, que
pueden cambiarse en tiempo de ejecucin y son muy dinmicos.
Clases que participan
a. FabricaAbstracta: Declara una interfaz para operaciones que crean
objetos productos abstractos.
b. FabricaConcreta: Implementa las operaciones para crear objetos
producto concretos.
c. ProductoAbstracto: Declara una interfaz para un tipo de objeto
producto.
d. ProductoConcreto: Define un objeto producto para que sea creado por
la fbrica correspondiente. Implementa la interfaz ProductoAbstracto.
e. Cliente: Slo usa interfaces declaradas por las clases.
Casos de aplicacin:
a. Un sistema deba ser independiente de cmo se crean, componen o
representan sus productos
b. Un sistema deba ser configurado con una de mltiples familias de
productos
c. Una familia de productos se disea para usarse a la vez y se quiere
reforzar esa restriccin

Cdigo ejemplo:
public abstract class
AbstractFactory {
public abstract Disco
comprarDisco();
public abstract Memoria
comprarMemoria();
}
public class AmdFactory
extends AbstractFactory{
public Disco
comprarDisco(){
return new DiscoAmd();
}
public Memoria
comprarMemoria(){
return new MemoriaAmd();
}

}
public class IntelFactory
extends AbstractFactory {

public Disco
comprarDisco() {
// TODO Auto-generated
method stub
return new DiscoIntel();
}
public Memoria
comprarMemoria() {
// TODO Auto-generated
method stub
return new MemoriaIntel();
}

}
public abstract class Disco
{
public abstract String
getDisco();
}
public abstract class
Memoria {
public abstract String
getMemoria();

}
public class DiscoAmd
extends Disco{
public String getDisco() {
return "Ha comprado un
Disco AMD";
}
}
public class DiscoIntel
extends Disco{

public String getDisco() {

// TODO Auto-generated
method stub
return "Ha comprado un
disco intel";
}
}
public class MemoriaAmd
extends Memoria{

public String getMemoria()

{
// TODO Auto-generated
method stub
return "Ha comprado una
memoria Amd";
}
}
public class MemoriaIntel
extends Memoria{

public String getMemoria()

{
// TODO Auto-generated
method stub
return "Ha comprado una
memoria intel";
}
}

Ventajas y desventajas del patrn de diseo de creacin Fabricacin

Abstracta.
Ventajas
Desventajas
Hace fcil el intercambio de familias de
productos, dado que en el momento de que
requiera lo nico que se debe hacer, es
cambiar o mejorar una lnea de cdigo
fomenta la consistencia entre productos.
Encapsula la responsabilidad de creacin
porque asla las clases concretas y ayuda a
mantener un control sobre las clases de
datos.

Puede ser difcil incorporar nuevos tipos

de datos. Pero esto se puede solucionar,
pasando un parmetro a los mtodos de
creacin de productos, pero con esto
sacrificara seguridad.

5.1.3. Builder
El objetivo es conseguir que la construccin de un objeto compuesto sea
independiente de su representacin, de manera que la construccin no se vea
afectada por el hecho de que cambie su forma de representacin.
Intencin
Construir de manera flexible un objeto complejo a partir de otro objeto complejo
en una serie de pasos.
Caso de aplicacin:
El patrn Builder se usa cuando:
El algoritmo para creacin de un objeto complejo debe ser
independiente de las partes que conforman el objeto y cmo estn
ensambladas.
El proceso de construccin debe permitir diferentes representaciones
del objeto que es contruido.
Ejemplo:
class Pizza {
private String masa = "";
private String salsa = "";
private String relleno = "";
public void setMasa(String
masa) { this.masa = masa;
}
public void setSalsa(String
salsa) { this.salsa =
salsa; }
public void
setRelleno(String relleno) {
this.relleno = relleno; }
}
abstract class PizzaBuilder
{
protected Pizza pizza;
public Pizza getPizza()
{ return pizza; }
public void
crearNuevaPizza() { pizza
= new Pizza(); }

public abstract void

buildMasa();
public abstract void
buildSalsa();
public abstract void
buildRelleno();
}
class HawaiPizzaBuilder
extends PizzaBuilder {
public void buildMasa()
{ pizza.setMasa("suave");
}
public void buildSalsa()
{ pizza.setSalsa("dulce"); }
public void buildRelleno() {
pizza.setRelleno("chorizo+
alcachofas"); }
}

class PicantePizzaBuilder
extends PizzaBuilder {
public void buildMasa()

{ pizza.setMasa("cocida");
}
public void buildSalsa()
{ pizza.setSalsa("picante");
}
public void buildRelleno() {
pizza.setRelleno("pimienta
+salchichn"); }
}

}
}

class Cocina {
private PizzaBuilder
pizzaBuilder;

public Pizza getPizza()

{ return pizza; }
public void
crearNuevaPizza() {
pizza = new Pizza();
buildMasa();
buildSalsa();
buildRelleno();
}

public void
setPizzaBuilder(PizzaBuilde
r pb) { pizzaBuilder = pb; }
public Pizza getPizza()
{ return
pizzaBuilder.getPizza(); }
public void construirPizza()
{
pizzaBuilder.crearNuevaPiz
za();
pizzaBuilder.buildMasa();
pizzaBuilder.buildSalsa();
pizzaBuilder.buildRelleno();
}
}
class BuilderExample {
public static void
main(String[] args) {
Cocina cocina = new
Cocina();
PizzaBuilder
hawai_pizzabuilder = new
HawaiPizzaBuilder();
PizzaBuilder
picante_pizzabuilder = new
PicantePizzaBuilder();
cocina.setPizzaBuilder( ha
wai_pizzabuilder );
cocina.construirPizza();
Pizza pizza =
cocina.getPizza();

abstract class
OtroPizzaBuilder {
protected Pizza pizza;

public abstract void

buildMasa();
public abstract void
buildSalsa();
public abstract void
buildRelleno();
}

class OtraCocina {
private OtroPizzaBuilder
pizzaBuilder;
public void
setPizzaBuilder(OtroPizzaB
uilder pb) { pizzaBuilder =
pb; }
public Pizza getPizza()
{ return
pizzaBuilder.getPizza(); }
public void construirPizza()
{
pizzaBuilder.crearNuevaPiz
za();
//notar que no se necesita
llamar a cada build.
}
}

5.1.4. Factory Method

Es un patrn que se ocupa en la creacin de objetos, sin especificar la
clase de objeto que se crear. Factory method se ocupa del problema
mediante la definicin de un mtodo para crear los objetos. Definiendo
una interfaz para crear objetos de tipo genrico permitiendo a las
subclases decidir qu tipo de objetos concreto crear.
Casos de aplicacin:

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:
Product: define la interfaz
de los objetos que el
mtodo factory va a crear.
ConcreteProduct: imple
menta la interfaz Product.
Creator: Declara
el
FactoryMethod(), el cual
retorna un objeto del tipo
Product(). Creator tambin puede definir una implementacin por
defecto del FactoryMethod() y retornar un objeto por defecto.
ConcreteCreator: Redefine el FactoryMethod() que retorna una
instancia ConcreteProduct
Ejemplo:
Sea un framework para la construccin de editores de documentos de
distintos tipos. Se nos presenta el dilema de que el framework es quien
sabe, a travs de su clase Aplicacin, cundo se debe crear un nuevo
documento, pero no sabe qu documento crear (slo conoce a la clase
abstracta o interfaz). La solucin de este dilema es encapsular el
conocimiento de cul es la subclase concreta del documento a crear y
mover ese conocimiento fuera del frameworK.
La implementacin del Factory method puede ser visible tambin en el
ejemplo descrito a continuacin, en el patrn de diseo creacional
Prototipo.

5.1.5. Prototype
El objetivo es ahorrar recursos con la creacin de objetos, la manera
ms eficiente de tener los objetos sin crearlos de nuevo es clonndolos.
Especifica los tipos de objetos a crear utilizando una instancia prototipo,
y
crea
nuevos
objetos
copiando
esta
instancia.
Casos de aplicacin:
En ciertos escenarios es preciso abstraer la lgica que decide que tipos
de objetos utilizar una aplicacin, de la lgica que luego usarn esos
objetos en su ejecucin. Los motivos de esta separacin pueden ser

variados, por ejemplo, puede ser que la aplicacin deba basarse en

alguna configuracin o parmetro en tiempo de ejecucin para decidir el
tipo de objetos que se debe crear.
Estructura

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
operacin por medio de la clonacin de s mismo

Ejemplo:
Se desea crear un programa en el cual se pueda crear figuras
geomtricas y estas se puedan copiar, en la cual dichas copias se
puedan personalizar sin afectar al objeto original.
Creamos la clase prototipo:

Creamos la clase Cuadrado que sera el prototipo concreto:

Creamos la clase Crculo que sera el prototipo concreto:

Luego creamos la clase ProbarFiguras que nos permitir crear

objetos a partir de objetos ya existentes en tiempo de ejecucin.

5.1.6. Singleton
Es un patrn 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.
Casos de aplicacin:
Usar cuando:

Deba a ver exactamente una instancia de una clase y sta

deba ser accesible a los clientes desde un punto de acceso
conocido.
La nica instancia debera ser extensible mediante herencia y
los clientes deberan ser capaces de utilizar una instancia
extendida sin modificar su cdigo.

Estructura:

El constructor de la clase debe

ser privado o protegido. No
puede ser pblico. Para
almacenar nuestra instancia
debemos crear un atributo que
sea esttico y privado. No
puede ser protegido, ni
pblico.
Hacemos un mtodo esttico de clase para crear el punto global de
acceso a nuestra nica instancia. Este mtodo debe retornar la
instancia nica.
Ejemplo:
public class Singleton
{
private static Singleton instance = null;
private Singleton() {}
public static Singleton GetInstance()
{
if (instance == null)
instance = new Singleton();
return instance;
}

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