- CONTINUACIÓN DEL DESARROLLO DEL TEMA CON EJEMPLOS:
TIPOS DE PATRONES:
Patrón Creador:
El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación (o instanciación) de nuevos objetos o clases.
La nueva instancia deberá ser creada por la clase que:
· Tiene la información necesaria para realizar la creación del objeto, o
· Usa directamente las instancias creadas del objeto, o
· Almacena o maneja varias instancias de la clase
· Contiene o agrega la clase.
Una de las consecuencias de usar este patron es la visibilidad entre la clase creada y la clase creador.
Una ventaja es el bajo acoplamiento, lo cual supone facilidad de mantenimiento y reutilizacion .La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.
Hay que diseñar la clase para que pueda instanciar otras clases sin depender de las clases que se instancia. La clase reutilizable es capaz de permanecer independiente de las instancias de clase delegando la elección de qué instancia se debe crear a otro objeto y referenciar el nuevo objeto creado a través de una interfaz común.
Ejemplo 1:
En la aplicación del punto de venta, ¿quién debería encargarse de crear una instancia VentasLineadeProducto? Desde el punto de vista del patrón Creador, deberíamos buscar una clase
que agregue, contenga y realice otras operaciones sobre este tipo de instancias
Una Venta agrega muchos objetos por ello, el patrón Creador sugiere que Venta es idónea para asumir la responsabilidad de crear las instancias VentasLineadeProducto.
Ejemplo 2:
Se quiere realizar una aplicación que permita realizar trabajos de edición sobre múltiples tipos de documentos
El patron creador seria FabricaDocumento, ya que es el que tiene la informacion para la creacion de los objetos.
Patrón Experto:
El GRASP de experto en información es el principio básico de asignación de responsabilidades. Nos indica, por ejemplo, que la responsabilidad de la creación de un objeto o la implementación de un método, debe recaer sobre la clase que conoce toda la información necesaria para crearlo. De este modo obtendremos un diseño con mayor cohesión y así la información se mantiene encapsulada (disminución del acoplamiento)
Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?
Solución: Asignar una responsabilidad al experto en información.
Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Se distribuye el comportamiento entre las clases que contienen la información requerida. Son más fáciles de entender y mantener.
Ejemplo:
Siguiendo con el ejemplo de antes En la aplicación del punto de venta, alguna clase necesita conocer el gran total de la venta. ¿Quién debería ser el responsable de conocer el gran total de la venta?
En la relación de conocimientos
Venta conoce el total de la venta
VentasLineadeProducto conoce el subtotal de la línea de producto
EspecificaciondeProducto conoce el precio del producto
Por lo que podemos asegurar que venta también es el patron experto en este ejemplo, ya que tiene la información del total de la venta.
Patron Controlador:
El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal forma que es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.
Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar la reutilización de código y a la vez tener un mayor control.
Se recomienda dividir los eventos del sistema en el mayor número de controladores para poder aumentar la cohesión y disminuir el acoplamiento.
Es importante destacar del patrón Controlador que los objetos de interfaz externa (ventanas, applets) y la capa de presentación no deben tener responsabilidad para satisfacer eventos del sistema. En otras palabras, los sistemas de operación deben ser manejados en el dominio de la capa de objetos en lugar de las capas de interfaz, presentación o aplicación de un sistema.
- REALIZACIÓN DE EJERCICIO DFD:
El enunciado del ejercicio de DFD es el siguiente:
Una empresa compra diferentes piezas a una serie de proveedores que posteriormente venderá a sus clientes, debiendo llevar a cabo el control del almacén (nº de piezas existentes de cada una de ellas).
La aplicación debe gestionar los proveedores, así como las piezas que proporcionan cada uno (proveedor y piezas con sus respectivos precios corresponden al flujo de entrada “proveedor”). Con los proveedores y las piezas que proporciona cada uno de ellos, se genera una lista de precios que se corresponde con los precios que consideremos mejores para cada una de las piezas que se puedan proporcionar al cliente (como criterio de selección se encuentra entre otros la marca de la pieza).
El control del almacén, es decir, las cantidades que tenemos de las diferentes piezas que hemos pedido a los proveedores (flujo de datos de “pieza stock”), determinará si el pedido realizado por el cliente (“pedido cliente”) se puede satisfacer completamente o no, según tengamos o no las piezas pedidas (generando en el caso de no tener dichas piezas un listado de ellas, “lista piezas”). Cuando el pedido se entrega al cliente, se genera la factura correspondiente.
Y su solución:
No hay comentarios:
Publicar un comentario