Upload
junior-orellana-valdez
View
217
Download
0
Embed Size (px)
DESCRIPTION
En este capítulo nos enfocaremos en conocer el Factory Pattern ("Patrón Fábrica"), clasificado como un patrón "Creacional", y en conjunto, iniciamos una primera introducción a los diagramas de secuencia
Citation preview
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
1
SEMANA 03:
“Patrón Fábrica“
Objetivos En este capítulo nos enfocaremos en conocer el Factory Pattern ("Patrón Fábrica"), clasificado como un patrón "Creacional", y en conjunto, iniciamos una primera introducción a los diagramas de secuencia. Referencia Wikipedia:
Factory Method
Diagrama de Secuencia
Intención del Patrón La intención de este patrón es "encapsular" o "centralizar" la creación de objetos.
La fábrica 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 decisión de cual retornar es enteramente de la fábrica.
No existe una relación directa entre quién requiere el objeto a la fábrica y el objeto entregado. La relación es indirecta, ya que a pesar que verdaderamente solo conoce a la fábrica, el código será afectado por cambios en el objeto recibido.
El objetivo es tener mayor control, orden o para ocultar complejidad en la creación de objetos, ya que estamos creando una nueva capa de abstracción que busca impedir el acceso o uso directo de los objetos en cuestión.
Existen distintos tipos de variantes de fábricas, pero lo importante es entender el concepto esencial que se aplica en todas de ellas.
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
2
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 diseño,
pero este tipo de diagramas es "estático y atemporal", ya que no nos transmite
en qué momento se inician las acciones y cómo se van anidando. Con el
diagrama de secuencia podemos ver cómo para este diseño decidimos que
Index creará las clases en el siguiente orden: primero Usuario, luego Admin y
luego Invitado.
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
3
Escenario 2
"Necesito encapsular la creación de objetos de tipo usuario" Solución 1: crear una
fábrica con métodos específicos para cada una de las instancias que debe
retornar.
En este nuevo diseño, escondemos el acceso directo a las clases y usamos como
intermediario a la clase "fábrica de usuarios", por lo tanto ya no tenemos un
acoplamiento con todas las clases, solo con quién los crea. A partir de centralizar
la creación de clases podemos ahora implementar cualquier funcionalidad sobre
ellas (logs, controles, restricciones, etc.).
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
4
Diagrama de secuencia mostrando el cambio en la invocación de los métodos de
cada clase, donde ahora toda la comunicación de Index será a través de la
Fábrica de Usuarios.
Codificación
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
5
Solución 2: la fábrica recibe parámetros que especifican qué tipo de objetos se
debe retornar.
Una variante en el diseño y codificación, pero el concepto de fábrica es el mismo.
Codificación
Escenario 2
Tengo un paquete que ofrece servicios que no quiero que accedan directamente
desde el exterior a todas mis clases
.
Solución: Fachada + Factory
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
6
Problema de diseño: alto acoplamiento entre clases clientes del paquete
Solución de diseño: aplicación de una Fachada para acceder a cualquier
contenido del paquete ("nueva capa de abstracción")
En este caso las clases que solicitan el servicio (Index1, 2 y 3) podrían necesitar
solo información específica de los usuarios, por lo que podrían no requerir
necesariamente el retorno de una instancia concreta. Para ese caso, la fábrica
soló servirá de intermediario y entregará los valores dentro de los objetos Usuario,
Admin e Invitado.
Un diseño alternativo puede ser una solución fachada + factory, donde se
retornará siempre una instancia que solicitan desde el exterior, y en vez de tener
una clase aparte para la fábrica, hacer un return new dentro de cada método de la
fachada (Fachada + Factory).
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
7
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.
Opción "pura", clase Fachada y Fábrica
Esta solución no es mejor ni peor, es otra solución, nada más.
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
8
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) más de diseño, donde
ahora quién llame desde el exterior debe conocer el nombre exacto de la clase
(detalle no menor), por lo que la abstracción no es el fuerte de esta solución.
Resumen Singleton, Fachada y Factory son los 3 primeros patrones que generalmente se
aprenden al principio de la lista del catálogo de patrones, principalmente por ser
simples y los más usados. A continuación empezaremos a entrar en una segunda
etapa donde aumentaremos la complejidad de los patrones y sus
implementaciones.
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
9
“Patrón Composite“
Objetivos En este capítulo nos enfocaremos en conocer el Composite Pattern ("Patrón Compuesto"), clasificado como un patrón "Estructural". Referencia Wikipedia:
Composite Pattern
Introducción Es muy probable que en algún momento de nuestra vida como desarrolladores
debamos enfrentarnos a un problema recurrente, conocido, típico 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 intención del patrón 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 distinción (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 genérica:
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
10
Veamos un ejemplo donde puede ser aplicable. Supongamos una aplicación 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 además la existencia de una operación, en este caso calcularTamano, aplicable tanto a elementos simples (archivos) como a elementos compuestos (directorios). El objetivo es lograr un diseño que permita trabajar tanto con archivos como con
directorios en forma indistinta, permitiendo además representar la naturaleza
recursiva de los directorios. Como ventaja adicional queremos además que sea
fácil agregar nuevos tipos de nodos que podrían surgir en el futuro, ya sean
compuestos o simples (por ej. Accesos directos o links).
Aplicaremos entonces el patrón, identificando como elemento compuesto a los
directorios y como elemento simple u hoja a los archivos. Una posible solución
podría ser así:
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
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. También es interesante analizar cuáles serían los pasos necesarios para agregar nuevos tipos de nodos. Este patrón Estructural hace uso de la recursividad y el diseño 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 diseño concreto (todo patrón plantea un diseño base que luego
podremos ajustar a nuestro contexto).
Ejemplo "Estructura de Directorios y Archivos"
UML
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
12
Codificación
index.php
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
13
Elemento.php
Archivo.php
Directorio.php
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
14
Próxima 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:
UNIVERSIDAD JOSÉ CARLOS MARIÁTEGUI INGENIERÍA DE SOFTWARE II
Ing. Walter Coayla Mamani.
15
Reglas: 1. La clase elemento se puede modificar 2. La búsqueda debe ser recursiva. Entrega:
UML y codificación 10
Resumen Este patrón 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 diseño abierto a la extensión y cerrado a la modificación.