UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

SEMANA 03:
Patrn Fbrica
Objetivos
En este captulo nos enfocaremos en conocer el Factory Pattern ("Patrn
Fbrica"), clasificado como un patrn "Creacional", y en conjunto, iniciamos una
primera introduccin a los diagramas de secuencia. Referencia Wikipedia:
1
Factory Method
Diagrama de Secuencia

Intencin del Patrn

La intencin de este patrn es "encapsular" o "centralizar" la creacin de objetos.

La fbrica recibe una solicitud de un determinado objeto y se encarga de

crearlo y retornarlo.
Retorna una instancia de varias posibles clases dependiendo de los datos
provistos.
La decisin de cual retornar es enteramente de la fbrica.
No existe una relacin directa entre quin requiere el objeto a la
fbrica y el objeto entregado. La relacin es indirecta, ya que a pesar que
verdaderamente solo conoce a la fbrica, el cdigo ser afectado por
cambios en el objeto recibido.
El objetivo es tener mayor control, orden o para ocultar complejidad
en la creacin de objetos, ya que estamos creando una nueva capa de
abstraccin que busca impedir el acceso o uso directo de los objetos en
cuestin.

Existen distintos tipos de variantes de fbricas, pero lo importante es entender el

concepto esencial que se aplica en todas de ellas.

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Escenario 1

Nuestra clase "cliente" (index) necesita trabajar con tres tipos de usuarios, para
ello, tiene acceso directo a las tres clases.

Los diagramas de clase son tiles para conocer las relaciones en nuestro diseo,
pero este tipo de diagramas es "esttico y atemporal", ya que no nos transmite
en qu momento se inician las acciones y cmo se van anidando. Con el
diagrama de secuencia podemos ver cmo para este diseo decidimos que
Index crear las clases en el siguiente orden: primero Usuario, luego Admin y
luego Invitado.

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Escenario 2
"Necesito encapsular la creacin de objetos de tipo usuario" Solucin 1: crear una
fbrica con mtodos especficos para cada una de las instancias que debe
retornar.

En este nuevo diseo, escondemos el acceso directo a las clases y usamos como
intermediario a la clase "fbrica de usuarios", por lo tanto ya no tenemos un
acoplamiento con todas las clases, solo con quin los crea. A partir de centralizar
la creacin de clases podemos ahora implementar cualquier funcionalidad sobre
ellas (logs, controles, restricciones, etc.).

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Diagrama de secuencia mostrando el cambio en la invocacin de los mtodos de

cada clase, donde ahora toda la comunicacin de Index ser a travs de la
Fbrica de Usuarios.

Codificacin

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Solucin 2: la fbrica recibe parmetros que especifican qu tipo de objetos se

debe retornar.

Una variante en el diseo y codificacin, pero el concepto de fbrica es el mismo.

Codificacin

Escenario 2
Tengo un paquete que ofrece servicios que no quiero que accedan directamente
desde el exterior a todas mis clases
.
Solucin: Fachada + Factory
Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Problema de diseo: alto acoplamiento entre clases clientes del paquete

Solucin de diseo: aplicacin de una Fachada para acceder a cualquier

contenido del paquete ("nueva capa de abstraccin")

En este caso las clases que solicitan el servicio (Index1, 2 y 3) podran necesitar
solo informacin especfica de los usuarios, por lo que podran no requerir
necesariamente el retorno de una instancia concreta. Para ese caso, la fbrica
sol servir de intermediario y entregar los valores dentro de los objetos Usuario,
Admin e Invitado.
Un diseo alternativo puede ser una solucin fachada + factory, donde se
retornar siempre una instancia que solicitan desde el exterior, y en vez de tener
una clase aparte para la fbrica, hacer un return new dentro de cada mtodo de la
fachada (Fachada + Factory).
Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Importante es entender la esencia de los patrones, y que no necesariamente hay

que cumplirlos al pi de la letra, ya que al final de cuentas quienes tienen que
adaptarlos a nuestras necesidades particulares somos nosotros.

Opcin "pura", clase Fachada y Fbrica

Esta solucin no es mejor ni peor, es otra solucin, nada ms.

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Ejemplo del manual de PHP

<?php
class Example
{
// The factory method
public static function &factory($type)
{
if (include_once 'Drivers/' . $type . '.php') {
$classname = 'Driver_' . $type;
return new $classname;
} else {
throw new Exception ('Driver not found');
}
}
}
?>
<?php
// Load a MySQL Driver
$mysql = Example::factory('MySQL');
// Load a SQLite Driver
$sqlite = Example::factory('SQLite');
?>

Aqu podemos apreciar otra variante:

(http://ar2.php.net/manual/es/language.oop5.patterns.php) ms de diseo, donde
ahora quin llame desde el exterior debe conocer el nombre exacto de la clase
(detalle no menor), por lo que la abstraccin no es el fuerte de esta solucin.

Resumen
Singleton, Fachada y Factory son los 3 primeros patrones que generalmente se
aprenden al principio de la lista del catlogo de patrones, principalmente por ser
simples y los ms usados. A continuacin empezaremos a entrar en una segunda
etapa donde aumentaremos la complejidad de los patrones y sus
implementaciones.

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Patrn Composite
Objetivos
En este captulo nos enfocaremos en conocer el Composite Pattern ("Patrn
Compuesto"), clasificado como un patrn "Estructural".
Referencia Wikipedia:
Composite Pattern

Introduccin
Es muy probable que en algn momento de nuestra vida como desarrolladores
debamos enfrentarnos a un problema recurrente, conocido, tpico y ya
resuelto, como puede ser la necesidad de implementar un algoritmo que
contemple recrear una estructura que se debe componer de forma recursiva,
es decir, que tenemos elementos que pueden contenerse unos a otros.

Composite
La intencin del patrn es componer objetos en una estructura de rbol,
permitiendo tratar objetos individuales y objetos compuestos recursivamente en
forma uniforme.
Es aplicable cuando los objetos se deben componer en forma recursiva, y no hay
distincin (o hay poca) entre objetos compuestos y componentes, y la estructura
se puede tratar en forma uniforme.
El siguiente diagrama describe su estructura en forma genrica:

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

10

Veamos un ejemplo donde puede ser aplicable. Supongamos una aplicacin en

la que se desea representar una estructura de archivos y directorios, donde
los directorios pueden ser compuestos en forma recursiva por archivos y/o otros
directorios.
Supongamos adems la existencia de una operacin, en este caso
calcularTamano, aplicable tanto a elementos simples (archivos) como a
elementos compuestos (directorios).
El objetivo es lograr un diseo que permita trabajar tanto con archivos como con
directorios en forma indistinta, permitiendo adems representar la naturaleza
recursiva de los directorios. Como ventaja adicional queremos adems que sea
fcil agregar nuevos tipos de nodos que podran surgir en el futuro, ya sean
compuestos o simples (por ej. Accesos directos o links).
Aplicaremos entonces el patrn, identificando como elemento compuesto a los
directorios y como elemento simple u hoja a los archivos. Una posible solucin
podra ser as:

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

11

Es importante notar como en el CalcularTamano() de directorio se tratan todos

los nodos del mismo de manera uniforme, sin importar si son directorios o
archivos. Tambin es interesante analizar cules seran los pasos necesarios para
agregar nuevos tipos de nodos.
Este patrn Estructural hace uso de la recursividad y el diseo estipula que la
clase superior que tenga que lidiar con los directorios y archivos, en s trabajar
con elementos que pueden ser cualquiera de los dos (herencia), o los que
requiera el diseo concreto (todo patrn plantea un diseo base que luego
podremos ajustar a nuestro contexto).

Ejemplo "Estructura de Directorios y Archivos"

UML

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

12

Codificacin
index.php

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Elemento.php

13

Archivo.php

Directorio.php

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

14

Prxima tarea
Requerimiento:
"Contamos con un sistema que tiene un disco duro en el cual se pueden
almacenar archivos y directorios. Se requiere desde Index poder decirle el nombre
de un archivo o directorio y nos retorne true / false si este elemento se encuentra
dentro del sistema"
La clase Elemento tendr esta nueva estructura:

Ing. Walter Coayla Mamani.

UNIVERSIDAD JOS CARLOS MARITEGUI

INGENIERA DE SOFTWARE II

Reglas:
1. La clase elemento se puede modificar
2. La bsqueda debe ser recursiva.
Entrega:
UML y codificacin
10

Resumen
Este patrn permite representar estructuras compuestas recursivamente y tratar a
todos los elementos de la estructura de la misma manera, sin importar que tipo de
elemento particular es.
Como ventaja asociada, facilita el agregado de nuevos componentes a la
estructura, manteniendo un diseo abierto a la extensin y cerrado a la
modificacin.

Ing. Walter Coayla Mamani.

15