aplicando una mejor base de datos

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.



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.



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



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



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



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



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.



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.



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:



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í:



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



12

Codificación

index.php



13

Elemento.php

Archivo.php

Directorio.php



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:



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.

aplicando una mejor base de datos

Documents