17 Patroness Oft Ware

Ingeniería de Software.
Patrones de Software.
Ingeniería de Software. Patrones de Software Página 0

Mapa del Proceso.

Concepto.
• Un patrón de software es:

“A description of communicating objects and classes that are
customized to solve a general design problem in a particular
context.”
• Inspirados por patrones de arquitectura “normal” (de construcciones
físicas).
• Libro de Gamma, Helm, Johnson y Vlissides (GoF) (*).
• Elementos esenciales:
• Nombre.
• Problema.
• Solución.
• Consecuencias o implicaciones.
* Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides. Addison Wesley Professional, 1994.

Niveles de Patrones de Software.
• Patrones Arquitectónicos.
• Describen soluciones al nivel más alto de software y
hardware.
• Normalmente soportan requerimientos no funcionales.
• Por ejemplo, MVC y PAC.
• Patrones de Diseño.
• Describen soluciones en el nivel medio de estructuras de
software.
• Usualmente soportan requerimientos funcionales.
• Patrones de Programación (Idioms).
• Describen soluciones en el nivel de software más bajo (clases
y métodos).
• Generalmente soportan características específicas de un
lenguaje de programación.
Los Patrones GoF Originales (1).
Creacionales
1. Singleton (y Multiton)
2. Factory Method
3. Abstract Factory
4. Builder
5. Prototype
Subrayado indica que se incluye explicación y ejemplo

Estructurales
6. Adapter
7. Bridge
8. Composite
9. Decorator
10. Façade
11. Flyweight
12. Proxy

Conductuales
13. Chain of responsibility 19. Observer
14. Command 20. State (*)
15. Intepreter 21. Strategy
16. Iterator 22. Template Method
17. Mediator 23. Visitor
18. Memento
* El patrón state se estudia en el capítulo de modelado de estado de objetos

complejos.

Los Patrones de JavaEE (1).
Presentation Tier
1. Intercepting Filter
2. Front Controller
3. Context Object
4. Application Controller
5. View Helper
6. Composite View
7. Service To Worker
8. Dispatcher view

Business Tier
9. Business Delegate
10. Service Locator
11. Session Façade
12. Transfer Object
13. Transfer Object Assembler
14. Application Service
15. Business Object
16. Composite Entity
17. Data Transfer Object
18. Value List Handler

Integration Tier
19. Data Access Object
20. ServiceActivator
21. Domain Store
22. Web Service Broker

El Patrón de Diseño Singleton (1).
“Idiom that is used to restrict instantiation of a class to a

one single object.”
• Es utilizado cuando se requiere exactamente un objeto para coordinar

acciones a través de una aplicación.
• Existe una variante llamada Multiton que es una generalización usada

para sistemas que operan más eficientemente cuando se requieren
exactamente n objetos de una clase.
• Si se usa exageradamente, introduce limitaciones innecesarias en

situaciones cuando realmente no se requiere una sola instancia. Debe
ser usado cuidadosamente.

Problema:
• Un sistema tiene una clase principal.

• Debe existir una sola instancia de esta clase.
• No se quiere que otros componentes sean capaces de crear otras
instancias de la clase principal.
Solución:
• Declarar el constructor de la clase principal como privado.

• Crear dentro de la clase principal una instancia de ella misma.
• Proporcionar un método estático que entregue la instancia a quien
la solicite.

MainClass
- singleton: MainClass
- MainClass()
<<static>>
+ getInstance(): MainClass

Ejemplo de Solución.
public class Singleton {
private static final Singleton INSTANCE = new Singleton();
// Private constructor prevents instantiation from other classes
private Singleton() { }
public static Singleton getInstance() {
return INSTANCE;
}
}
public class Componente {

private Singleton myInstance = new Singleton(); // inválido
private Singleton myInstance = Singleton.getInstance() ; // ok
}

El Patrón de Diseño Factory Method.
“Define an interface for creating an object, but let the

subclasses decide which class to instantiate. The Factory
method lets a class defer instantiation to subclasses.”
• Define un método separado cuya función es la creación de objetos.

• No es necesario especificar la clase exacta de la que proviene el
objeto creado.
• Las subclases pueden hacer un override para especificar el tipo
derivado del objeto que crean.
• Más generalmente, el término Factory Method se emplea para
cualquier método cuyo propósito principal es la creación de objetos.

El Patrón de Diseño Factory Method (2).
Problema:
• No existe un mecanismo simple para crear objetos sin especificar

su clase exacta.
Solución:
• Crear una clase Factory que tiene un método createXXX.
• Las clases que deseen crear objetos de clase Factory deben utilizar
el método createXXX.


Consecuencias:
• +
• Se pueden agregar subclases de productos en
forma transparente.
• Proporciona un mecanismo standard de creación
de objetos.
•-
• Overhead en el proceso comparado con new()
simple.

public abstract class Pizza {

public abstract double getPrice();
}
public class HamAndMushroomPizza extends Pizza {

private double price = 8.5;
public double getPrice() {
return price;
}
}

public class DeluxePizza extends Pizza {

return price;
}
}
public class HawaiianPizza extends Pizza {

return price;
}
}

public class PizzaFactory {

public enum PizzaType {
HamMushroom, Deluxe, Hawaiian
}
public static Pizza createPizza(PizzaType pizzaType) {
switch (pizzaType) {
case HamMushroom: return new HamAndMushroomPizza();
case Deluxe: return new DeluxePizza();
case Hawaiian: return new HawaiianPizza();
}
System.out.println ("The pizza type “+pizzaType+“ is not recognized.");
return null;
}
}
public class PizzaLover {

public static void main (String args[ ]) {
for(PizzaFactory.PizzaType pizzaType: PizzaFactory.PizzaType.values() ) {
System.out.println("Price of " + pizzaType + " is " +
PizzaFactory.createPizza(pizzaType).getPrice());
}
}
}

El Patrón de Diseño Abstract Factory (1).
“Provide an interface for creating families of related or

dependent objects without specifying their concrete classes.”
• Proporciona una manera de encapsular un grupo de fábricas individuales

que tienen un tema común.
• En el uso normal, el cliente crea una implementación concreta de la

Abstract Factory y usa las intefaces genéricas que crean los objetos
concretos que son parte del tema común.
• El cliente no sabe (ni le interesa) que objetos concretos obtiene de cada

una de las fábricas internas puesto que sólo usa las interfaces genéricas
para crear sus productos.
• Normalmente se implementa usando Factory Method.

Problema:
• Un sistema consta de varias familias de productos.

• Cada familia está diseñada para ser usada como un todo.
• No se quieren revelar las clases que implementan las familias.
Solución:
• Crear una clase abstracta o interfaz, AbstractFactory que tiene un

método createXXX para cada tipo de producto.
• Crear una clase concreta, ConcreteFactoryN que implemente los
métodos createXXX para cada tipo de producto y que entregue un
producto concreto.


Consecuencias:
• +
• Aísla las clases concretas (principio de
inversión de la Dependencia).
• Facilita intercambiar familias de productos.
• Promueve la consistencia entre productos.
•-
• Es difícil soportar nuevas clases de productos.

Ejemplo de Abstract Factory (1).
/* GUIFactory example -- */
public interface GUIFactory {

public Button createButton();
}
public class WinFactory implements GUIFactory {
public Button createButton() {
return new WinButton();
}
}
public class LinuxFactory implements GUIFactory {
public Button createButton() {
return new LinuxButton();
}
}

public interface Button {

public void paint();
}
public class WinButton implements Button {
public void paint() {
System.out.println("I'm a WinButton"); }
}
public class LinuxButton implements Button {
public void paint() {
System.out.println("I'm a LinuxButton");
}
}
public class Application {
public Application(GUIFactory factory) {
Button button = factory.createButton();
button.paint();
}
}
public class ApplicationRunner {

private static String OS = "Win";
public static void main(String[ ] args) {
if (args.length != 0) { OS = args[0]; }
else { OS = "Win"; }
new Application(createOsSpecificFactory());
}
public static GUIFactory createOsSpecificFactory() {
if (OS.equals("Win")) {
return new WinFactory();
} else {
return new LinuxFactory();
}
}
}

El Patrón de Diseño Composite (1).
“Compose objects into tree structures to represent part-whole

hierarchies. Composite lets clients treat individual objects and
compositions of objects uniformly.”
• Composite permite que un grupo de objetos sean tratados de la misma

manera que cada elemento del grupo.
• El intento de composite es integrar objetos en estructuras tipo árbol que

representen las jerarquías del todo (compuesto) y las partes.
• Composite permite a los clientes tratar objetos individuales y compuestos

de esos objetos uniformemente.

Problema:
• Se quieren representar jerarquías de objetos de tipo parte y

compuestos.
• Se quiere usar la misma interfaz en las partes y en los compuestos.
Solución:
• Crear una interfaz o clase abstracta, Component, que actúe como

superclase de las clases concretas que representan las partes y los
compuestos.
• Las clases que representan los compuestos pueden ser tratadas
como partes, porque soportan la interfaz Component.

Estilo original:

Estilo alterno:

Consecuencias:
• +
• Hace el cliente simple.
• Facilita la agregación de nuevos tipos de
componentes
• -
• Puede hacer el modelo de diseño
demasiado general.

Ejemplo de Composite (1).
// Interfaz general
import java.util.List;
import java.util.ArrayList;
public interface Graphic {
// Prints the graphic.
public void print();
}
// Composite
import java.util.*;
public class CompositeGraphic implements Graphic {
// Collection of child graphics.
private List<Graphic> mChildGraphics = new ArrayList<Graphic>();
public void print() {
for (Graphic graphic : mChildGraphics) {
graphic.print();
}

// Adds the graphic to the composition.

public void add(Graphic graphic) {
mChildGraphics.add(graphic);
}
// Removes the graphic from the composition.
public void remove(Graphic graphic) {
mChildGraphics.remove(graphic);
}
}
// Leaf
public class Ellipse implements Graphic {
public void print() {
System.out.println("Ellipse");
}
}
// Client
public class Program {
public static void main(String[] args) {
// Initialize four ellipses
Ellipse ellipse1 = new Ellipse();
// Initialize three composite graphics
CompositeGraphic graphic = new CompositeGraphic();
CompositeGraphic graphic1 = new CompositeGraphic();
CompositeGraphic graphic2 = new CompositeGraphic();
// Composes the graphics
graphic1.add(ellipse1);

graphic.add(graphic1);
graphic.add(graphic2);
// Prints the complete graphic (four times the string "Ellipse").
graphic.print();
}
}

El Patrón de Diseño Façade (1).
“A façade is an object that provides a simplified interface to a larger

body of code, such as a class library. ”
• Logra que un conjunto de clases de software sea más fácil de usar y

entender puesto que proporciona métodos homogéneos para tareas
comunes.
• Hace que el código que usa las clases sea más claro y legible.
• Reduce dependencias de código exterior en el código del conjunto de

clases puesto que la mayoría del código usa la fachada, lo cual permite
mayor flexibilidad en el desarrollo del sistema.
• Encapsula una colección de APIs diseñadas pobremente en una sola

API bien diseñada.

Problema:
• Se tienen una serie de clases que hacen funciones similares pero
que tienen métodos diferentes.
• Las clases no están diseñadas homogéneamente.
Solución:
• Crear una clase Façade que incluya las diferentes clases como
atributos.
• Hacer que los clientes utilicen la clase Façade en vez de las

clases independientes.


Consecuencias:
• +
• Mantiene el cliente simple y limpio.
• Reduce la complejidad de acceso a subsistemas.
• Permite la reutilización de sistemas legado con una nueva
interfaz.
•-
• Mayor número de clases.
• Difícil de probar.

Ejemplo de Façade (1).
// Complex parts
public class CPU {
public void freeze() { ... }
public void jump(long position) { ... }
public void execute() { ... }
}
public class Memory {
public void load(long position, byte[ ] data) { ... }
}
public class HardDrive {
public byte[ ] read(long lba, int size) { ... }
}
public class Computer { // Façade
public void startComputer( ) {
cpu.freeze();
memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR,SECTOR_SIZE));
cpu.jump(BOOT_ADDRESS);
cpu.execute();
}
}

Ejemplo de Façade (2).
// Client
public class User {
Computer facade = new Computer();
facade.startComputer();
}
}

El Patrón de Diseño Strategy (1).
“Define a family of algorithms, encapsulate each one, and make

them interchangeable. Strategy lets the algorithm vary
independently from clients that use it.”
• Es utilizado en situaciones donde es necesario intercambiar

dinámicamente los algoritmos usados en una aplicación.
• Su función es proporcionar un medio para definir una familia de

algoritmos, encapsular cada uno de ellos como un objeto y hacerlos
intercambiables.
• Permite que los algoritmos varíen independientemente de los clientes que

los utilicen.
• A Strategy is an object that represents an algorithm.

Problema:
• Se tiene un conjunto de clases que sólo difieren en los algoritmos

que usan.
• Se quiere cambiar de algoritmo en el momento de la ejecución.
Solución:
• Crear una interfaz, Strategy, que sea implementada por un

conjunto de clases concretas.
• En tiempo de ejecución, seleccionar una instancia de estas clases
particulares dentro de otra clase Context, que contiene referencias
a la interfaz Strategy.


Consecuencias:
• +
• Alternativa a usar subclases.
• Elimina postulados condicionales en la
implementación.
• -
• Overhead entre Strategy y Context.
• Se incrementa el número de objetos.

Ejemplo de Strategy (1).
// The classes that implement a concrete strategy should implement this.

// The context class uses this to call the concrete strategy
public interface Strategy {
int execute(int a, int b);
}
// Implements the algorithm using the strategy interface

public class ConcreteStrategyAdd implements Strategy {
public int execute(int a, int b) {
System.out.print("Called ConcreteStrategyA's execute() ");
return (a + b);
}
}

public class ConcreteStrategySubtract implements Strategy {

System.out.print("Called ConcreteStrategyB's execute() ");
return (a - b);
}
}
public class ConcreteStrategyMultiply implements Strategy {
System.out.print("Called ConcreteStrategyC's execute() ");
return a * b;
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a

// Strategy object
public class Context {
Strategy strategy;
public Context(Strategy strategy) {
this.strategy = strategy;
}
return strategy.execute(a, b);
}
}

public class StrategyExample {

Context context;
// Three contexts following different strategies
context = new Context(new ConcreteStrategyAdd());
int resultA = context.execute(3,4);
System.out.println(resultA);
context = new Context(new ConcreteStrategySubtract());
int resultB = context.execute(3,4);
System.out.println(resultB);
context = new Context(new ConcreteStrategyMultiply());
int resultC = context.execute(3,4);
System.out.println(resultC);
}
}

El Patrón de Diseño Observer (1).
“Define a one-to-many dependency between objects so that

when one object changes, all its dependents are notified and
updated automatically.”
• En este patrón, un objeto llamado el subject u observable, mantiene una

lista de sus dependientes, llamados observers.
• El subject notifica a sus observadores de cualquier cambio en su

estado.
• La notificación normalmente es mediante llamados a un método especial

de los observadores.

Problema:
• Se necesita notificar a un conjunto de objetos que ha ocurrido un

evento.
• El conjunto de objetos puede cambiar en el momento de la
ejecución.
Solución:
• Crear una clase abstracta, Subject, que mantenga una colección

de objetos Observer.
• Cuando ocurre un cambio, se notifica a todos los observadores.


Consecuencias:
• +
• Acoplamiento abstracto entre Subject y Observer.
• Soporte para notificaciones en modo multicast.
• -
• Actualizaciones no esperadas en los
observadores.

Ejemplo de Observer (1).
import java.util.Observable;
import java.io.*
public class EventSource extends Observable implements Runnable { // Subject
public void run() {
try {
final InputStreamReader isr = new InputStreamReader( System.in );
final BufferedReader br = new BufferedReader( isr );
while( true ) {
final String response = br.readLine();
setChanged(); // implementado en la clase Observable
notifyObservers(response); // implementado en la clase Observable
}
} catch (IOException e) {
e.printStackTrace();
}
}
}

import java.util.Observable;
import java.util.Observer;
public class ResponseHandler implements Observer { // Observer
private String resp;
public void update (Observable obj, Object arg) {
if (arg instanceof String) {
resp = (String) arg;
System.out.println("\nReceived Response: "+ resp );
}
}
}

public class MyApp {

public static void main(String args[ ]) {
System.out.println("Enter Text >");
// create an event source - reads from stdin
final EventSource evSrc = new EventSource();
// create an observer final
ResponseHandler respHandler = new ResponseHandler() ;
// subscribe the observer to the event source
evSrc.addObserver( respHandler );
// starts the event thread
Thread thread = new Thread(evSrc);
thread.start();
}
}

Ejercicio.
• Presentar los siguientes patrones por equipo:
Patrón Equipo Patrón Equipo

Prototype 7 Interpreter 10
Builder 2 Bridge 3
Adapter 5 Mediator 8
Command 9 Template Method 4
Iterator 6 Visitor 1

Tarea (continuación).
• Contenido de la presentación:
o Descripción general del patrón.

o Problema.
o Solución.
o Diagrama de clases.
o Consecuencias positivas y negativas.
o Ejemplo.
• Desarrolladas en PowerPoint.

17 Patroness Oft Ware

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

17 Patroness Oft Ware

Hochgeladen von

Copyright:

Verfügbare Formate

Ingeniería de Software.

Ingeniería de Software. Patrones de Software Página 0

Ingeniería de Software. Patrones de Software Página 1

• Un patrón de software es:

Ingeniería de Software. Patrones de Software Página 2

Subrayado indica que se incluye explicación y ejemplo

Subrayado indica que se incluye explicación y ejemplo

* El patrón state se estudia en el capítulo de modelado de estado de objetos

Subrayado indica que se incluye explicación y ejemplo

Ingeniería de Software. Patrones de Software Página 6

Ingeniería de Software. Patrones de Software Página 7

Ingeniería de Software. Patrones de Software Página 8

Ingeniería de Software. Patrones de Software Página 9

“Idiom that is used to restrict instantiation of a class to a

• Es utilizado cuando se requiere exactamente un objeto para coordinar

• Existe una variante llamada Multiton que es una generalización usada

• Si se usa exageradamente, introduce limitaciones innecesarias en

Ingeniería de Software. Patrones de Software Página 10

• Un sistema tiene una clase principal.

• Declarar el constructor de la clase principal como privado.

Ingeniería de Software. Patrones de Software Página 11

Ingeniería de Software. Patrones de Software Página 12

public class Componente {

Ingeniería de Software. Patrones de Software Página 13

“Define an interface for creating an object, but let the

• Define un método separado cuya función es la creación de objetos.

Ingeniería de Software. Patrones de Software Página 14

• No existe un mecanismo simple para crear objetos sin especificar

• Crear una clase Factory que tiene un método createXXX.

Ingeniería de Software. Patrones de Software Página 15

Ingeniería de Software. Patrones de Software Página 16

Ingeniería de Software. Patrones de Software Página 17

public abstract class Pizza {

public class HamAndMushroomPizza extends Pizza {

Ingeniería de Software. Patrones de Software Página 18

public class DeluxePizza extends Pizza {

public class HawaiianPizza extends Pizza {

Ingeniería de Software. Patrones de Software Página 19

public class PizzaFactory {

public class PizzaLover {

Ingeniería de Software. Patrones de Software Página 21

“Provide an interface for creating families of related or

• Proporciona una manera de encapsular un grupo de fábricas individuales

• En el uso normal, el cliente crea una implementación concreta de la

• El cliente no sabe (ni le interesa) que objetos concretos obtiene de cada

• Normalmente se implementa usando Factory Method.

Ingeniería de Software. Patrones de Software Página 22

• Un sistema consta de varias familias de productos.

• Crear una clase abstracta o interfaz, AbstractFactory que tiene un

Ingeniería de Software. Patrones de Software Página 23

Ingeniería de Software. Patrones de Software Página 24

Ingeniería de Software. Patrones de Software Página 25

public interface GUIFactory {

Ingeniería de Software. Patrones de Software Página 26

public interface Button {

public class ApplicationRunner {

Ingeniería de Software. Patrones de Software Página 28

“Compose objects into tree structures to represent part-whole

• Composite permite que un grupo de objetos sean tratados de la misma

• El intento de composite es integrar objetos en estructuras tipo árbol que

• Composite permite a los clientes tratar objetos individuales y compuestos

Ingeniería de Software. Patrones de Software Página 29

• Se quieren representar jerarquías de objetos de tipo parte y

• Crear una interfaz o clase abstracta, Component, que actúe como