Patrones Estructurales

Contenido

Objetivos2Introduccin3Patrn Decorator4Patrn Composite6Patrn Fachada10Patrn Flyweight12Patrn Adapter14

Objetivos

Objetivo General Entender la aplicacin de los patrones estructurales, y como es su aplicacin segn la situacin necesario que se requiere para la construccin del softwareObjetivos Especficos Ejemplificar cada patrn, como lo son los patrones adaptador, puente, composicin, decorador, fachada, proxy, peso ligero Identificar las ventajas y desventajas de la aplicacin de los patrones estructurales

Introduccin

Los patrones de diseo son las soluciones a problemas que se pueden presentar en varias ocasiones en la construccin de software, este es recurrente al igual que el ncleo de la solucin a ese problema, segn Gamma, estos patrones son una descripcin de clases y objetos comunicndose entre s, que se adapta para resolver un problema de diseo.En este trabajo se mostrara a travs de ejemplos a cerca de los patrones estructurales tales como son adaptador, puente, composicin, decorador, fachada, proxy y peso ligeroAdems, se mostrara las ventajas y desventajas que tiene cada patrn en la creacin de objetos, y a la hora del desarrollo de un software aplicando alguno de estos patrones.

Patrn DecoratorEn una clase de dibujo, se usa un lpiz especial, con este lpiz obviamente se realizan los diferentes trazos con este, pero en algunas ocasiones es necesario borrar algo muy pequeo sin daar el resto del trazo con la otra punta del lpiz, adems en algunas ocasiones despus de un tiempo es necesario que los estudiantes utilicen un sujetador, para que haya un trazado ms fuerte y preciso con el lpiz sin que este resbale y dae el resto del trazo que se est trabajando.Cmo aadirle la funcionalidad de borrado y de sujetador al lpiz en el momento que sea necesario y no durante toda la clase?Para esto usaremos el patrn estructural Decorator o decorador, por lo que crearemos una clase abstracta lpiz que va a heredar a un lpiz concreto y a un decorador de lpiz abstracto (aunque esto ltimo no tiene sentido, se usa como un jugada maestra) y a su vez se generan los dos decoradores concretos que necesitamos como lo son el borrador y el sujetador. Este decorador abstracto tiene una agregacin con el lpiz abstracto, ya que al decorador se le adiciona al lpiz y no el caso contrario.Para esto mostraremos el cdigo donde le adicionamos el decorador al lpiz. (Figura 1)En el main o launcher, vemos primero que instanciamos un lpiz, y luego instanciamos el decorador borrador y el decorador sujetador, y como parmetros a la hora de instanciarlos le pasamos el lpiz concreto que ya habamos creado anteriormente, e igualmente podemos seguir dibujando sin realizar ningn cambio en tiempo de ejecucin. En la siguiente parte del cdigo vemos que extraemos cada uno de los decoradores, y este sigue siendo un lpiz con el cual podemos dibujar Esa es la ventaja del patrn, que podemos adicionar o remover dinmicamente las funcionalidades que tiene el lpiz, pero puede llegar al punto de que se crean muchos decoradores pequeos, y as complica la depuracin.

Figura 1. Figura 2La anterior grfica (Figura 2), es el diagrama de clases que representa el escenario y el cdigo anteriormente vistos. Aqu podemos observar la explicacin que se dio despus de realizarnos la pregunta, para complementar, dentro de la clase Borrador, por ejemplo, podemos observar que existe un mtodo protegido que es borrar, ya que a la hora de llamar al mtodo dibujar de la clase borrador, all nos dar la opcin de que si queremos que el mtodo borrar sea utilizado o no, lo mismo pasa con el mtodo sujetar de la clase sujetador. Patrn CompositeUna empresa inmobiliaria se encarga adems de vender casas y dems, de trastear a una persona a su nuevo inmueble, la mayora de ocasiones en los trasteos transportan bibliotecas o armarios, existen dos formas de mover estas bibliotecas o armarios, una es moviendo gabinete por gabinete y luego volver a unirlo al pasar la revestimiento o pasar toda la biblioteca o el armario, con todos los gabinetes adentro, y transportar todos de una sola vez, ahorrando tiempo y de pronto dinero. Pero en algunas ocasiones, el cliente pide que uno de todos los gabinetes de su armario, sea puesto en otro lugar.Cmo transportar la biblioteca o armario del cliente sin necesidad de transporta cada uno de los gabinetes que lo conforman, y que los gabinetes sean independientes a la biblioteca o armario?Para esto usamos el patrn Composite o composicin, para lo que creamos una clase abstracta gabinete que a su vez herede a un Gabinete Simple y a un Gabinete Compuesto que ser el armario o la biblioteca. A su vez este Gabinete compuesto, tiene una agregacin de gabinete abstracto, ya que un gabinete compuesto, tiene varios gabinetes simples, e incluso puede tener otros gabinetes compuestos.Primeramente (Figura 3) vemos el cdigo en Java de la clase Gabinete Compuesto, como podemos ver, dentro de este hemos creado un arreglo dinmico de gabinetes en el cual lo hemos llamado biblioteca, all estarn todos los gabinetes, ya sean simples o compuesto que pertenezcan a la biblioteca, adems vemos el mtodo agregar, en donde pasamos como parmetro un gabinete, y este nos lo adiciona y nuestra biblioteca, a la hora de mover la biblioteca, tenemos que mover todos los gabinetes por medio de un ciclo, y por ultimo podemos retirar un gabinete, ya sea simple o compuesto cuando se haya terminado de mover el armario o biblioteca, o simplemente cuando deseamos cambiarlo.

Figura 3. Ahora vemos el main o launcher (Figura 4), en donde primero instanciamos dos (2) gabinetes simples y luego instanciamos el gabinete compuesto que es la biblioteca o el armario, luego agregamos los dos gabinetes simples a la biblioteca o al armario, para despus moverlos todos juntos a una posicin (10, 15), cuando miramos el mtodo ver (Que nos muestra la posicin de los gabinetes simples), podemos darnos cuenta que se encuentran en la misma posicin de la biblioteca o gabinete. Luego retiramos uno de los gabinetes simples, y movemos el resto a la siguiente posicin (20, 30), al mirar la posicin del gabinete que todava se encuentra dentro de la gabinete compuesto vemos que se movi a la posicin al cual habamos dirigido, pero el gabinete simple que retiramos del gabinete compuesto sigui en la posicin en la que lo habamos dejado antes que fue la posicin (10, 15).

Figura 4

En la siguiente grfica (Figura 5), veremos el diagrama de clases del escenario anterior, en la cual se especifica la explicacin que se dio despus de haberse realizado la pregunta. La ventaja de este patrn es que se puede representar una categora de objetos como parte de un todo, y de esta manera se ignora la idea de cuales son objetos que son compuestos o que son objetos simples, el problema es que al igual que pasa cuando llevamos un armario con todos sus gabinetes, puede pesar ms de la cuenta, por lo que s es un objeto que tiene demasiados objetos simples puede ocupar ms memoria de la cuenta.

Figura 5.

Patrn Fachada Se est creando un servicio web de llamadas virtuales, este servicio deber permitir la salida de llamadas a travs de la red de internet con el protocolo Voz IP; la aplicacin cuenta con varios mdulos como agenda de contactos, llamadas, vdeo llamada, etc. A cada uno de estos servicios se debe acceder de manera sencilla para que cualquier aplicacin que lo llame pueda utilizarlo de manera efectiva. Uno de los mdulos del servicio deber permitir realizar una llamada, dejarla en espera o finalizarla, teniendo en cuenta cada uno de los componentes del protocolo y otros servicios, tales como conexin, encriptacin, digitalizacin, compresin y envi.Uno de los inconvenientes ms grandes en el desarrollo de este mdulo es cmo facilitar el uso del framework o de la interfaz del servicio web para que sea fcilmente usado por cualquier aplicacin de escritorio?Una de las soluciones ms factibles es la implementacin del patrn fachada con el fin de ocultar el comportamiento interno de los mdulos del protocolo a los clientes del servicio web quienes solo accedern al servicio de llamadas.El patrn fachada definir una interfaz que definir los servicios a ser llamados por los clientes, para permitir de esta manera el uso de los componentes del protocolo de forma indirecta (a travs de la interfaz) sin necesidad de que el cliente sepa los servicios que estos componentes proveen.A continuacin (Figura 6) se tiene el diagrama de clases que define la solucin propuesta ante el problema planteado. Figura 6.

El diagrama anterior muestra una clase Llamada que funcionara como una interfaz (como clase de acceso, no propiamente una interfaz abstracta) hacia los servicios que necesita el cliente sin que este conozca el funcionamiento interno del sistema de llamadas tales como el protocolo y la forma de encriptar, por tanto el cliente simplemente se comunicara con la interfaz Llamada que le brindara los servicios de manera eficaz, la comunicacin del cliente al servidor se har entonces de la siguiente manera. Patrn FlyweightSe desea construir un videojuego del tipo Space Invader donde la nave tendr que destruir a los aliengenas, la nave tiene tres tipos de armamento: bombas, balas bsicas y balas explosivas. La velocidad mxima que la nave puede disparar es tres balas cada dos segundos por lo que el escenario puede contener una cantidad grande de balas antes de que salgan de la pantalla.En el escenario cada una de las balas gastara un espacio en memoria por lo que al momento de que la nave dispare las balas de manera continua a su velocidad mxima se puede congestionar la memoria que almacena estos objetos, por tanto cmo se podra reducir el peso de cada bala para que no congestionen la memoria?La solucin ms factible para este problema es la implementacin del patrn flyweight (peso ligero) que permite instanciar una nica vez lo que varios objetos tienen en comn y compartir este objeto con el fin de aligerar la memoria.Para implementar el patrn en este problema se declara un objeto de tipo Flyweight que contendr los atributos que varias de las balas tienen en comn y que compartirn al ser instanciadas, de esta clase se heredara BalaCompartida que ser la parte que tienen en comn, por ltimo la clase FlyweightFactory que almacenara los objetos BalaCompartida para devolvrselos al objeto Bala cuando lo pida.

En este caso los atributos que la mayora de las balas comparten son la textura(imagen), la potencia, la velocidad y el origen; los nicos atributos que no comparten son la posicin en X y la posicin en Y en el escenario, a continuacin (Figura 7) la estructura de la solucin propuesta.

Figura 7.La clase Bala ser el cliente propiamente dicho en el patrn, cuando se ejemplifica la clase Bala a travs de su constructor se asigna a sus atributos los valores de X y Y, pero los dems atributos que son compartidos se los encarga a la fabrica de pesos ligeros (FlyweightFactory) quien s elos devolver de forma encapsulada en un objeto de tipo BalaCompartida. FlyweightFactory busca en su Piscina o Pool donde almacena los objetos compartidos, y si encuentra el objeto que cumpla con los parmetros (clave) que le pide la Bala ser regresado de lo contrario crea un objeto BalaCompartida, lo agrega a su piscina por si en un futuro ms objetos lo necesitan y lo retorna a la Bala.

El nico cdigo relevante para la solucin del problema es el que se muestra comentado en el diagrama estructural del patrn por lo que no es necesario anexar otro fragmento de cdigo.Patrn Adapter

Supongamos que tenemos un sistema que trabaja con diferentes tipos de motores (a gas y a gasolina) que comparten caractersticas comunes as como su funcionamiento, se desea vincular al sistema una clase de tipo motor Elctrico con un funcionamiento diferente al de los dems, se debe adaptar la nueva clase sin que esto afecte la lgica inicial de la aplicacin.Ya que nos plantean vincular un nuevo motor totalmente diferente al resto de motores definido en el sistema, entonces deducimos que si bien es un motor no puede tener un tratamiento igual al de los dems, ya que el modo de encenderlo, ponerlo en funcionamiento y hasta apagarlo podra ser muy distinto, afectando la lgica establecida; como no podemos modificar bruscamente nuestro cdigo entonces utilizaremos el patrn Adapter para dar solucin a nuestra problemtica. Como vemos en la figura (Figura 8) nuestro sistema gira en torno a los motores, utilizamos la herencia para compartir funcionalidades comunes para los diferentes tipos de motores con los que se trabajar, sin embargo se puede detallar que no todos ellos se comportan de la misma manera como es el caso del Motor Elctrico, por tal razn no se puede ponerlo a heredar directamente de la clase Motor, ya que los mtodos que ella provee no seran tiles para esta clase.En este punto es donde hacemos uso de una clase Adapter que servira de puente entre la clase Padre y La Clase que debe ser adaptada, as este adaptador sera el encargado de establecer comunicacin con el motor Elctrico y ejecutar las solicitudes que el cliente realice. Figura8Aqu (Figura 9) se establece el puente por medio del cual la clase incompatible puede ser utilizada, hereda de la clase Motor y por medio de la implementacin dada, realiza la comunicacin con la clase a adaptar usando para esto una instancia de la misma.Finalmente esta clase(Figura 10) representa el Cliente del sistema que usa los diferentes tipos de motores, como vemos desde aqu se hacen los llamados sin importar cual es la lgica detrs de estos, por medio del patrn Adapter llamamos a los mismos mtodos encender(), acelerar() o apagar(), siendo transparente el proceso interno que se realiza. podemos evidenciar tambin como se utiliza el polimorfismo para hacer este tipo de llamados.

Figura 9.Figura 10Patrn Bridge

En el siguiente ejemplo, se lleva acabo la solicitud de un pedido en un concecionario, donde el cliente elige los diferentes tipos de vehculos y un diferente tipo de motor disponible.

xPatrn Proxy

El patrn Proxy es muy verstil. Puede ser utilizado en infinitas ocasiones y se le puede otorgar varios usos. Tiene una gran ventaja y es que no obliga al desarrollador a crear demasiada estructura para realizar este patrn, sino que es una forma estndar de acceder a una clase que potencialmente puede ser conflictiva. Por otro lado, no ayuda al desarrollador a crear un algoritmo, sino que el desarrollador tiene que hacer toda la lgica.

Por estas razones, es un patrn donde no siempre se puede saber a priori cuando utilizarlo. Sin embargo, un Proxy es un concepto utilizado fuera del mbito de los patrones de diseo: un servidor proxy es un equipo intermediario situado entre el sistema del usuario e Internet. Puede utilizarse para registrar el uso de Internet y tambin para bloquear el acceso a una sede Web. El servidor de seguridad del servidor proxy bloquea algunas redes o pginas Web por diversas razones. En consecuencia, es posible que no pueda descargar el entorno de ejecucin de Java (JRE) o ejecutar algunos applets de Java.Es decir, los servidores proxy funcionan como filtros de contenidos. Y tambin mejoran el rendimiento: guardan en la memoria cach las pginas Web a las que acceden los sistemas de la red durante un cierto tiempo. Cuando un sistema solicita la misma pgina web, el servidor proxy utiliza la informacin guardada en la memoria cach en lugar de recuperarla del proveedor de contenidos. De esta forma, se accede con ms rapidez.

Este mismo concepto se intenta llevarlo a cabo a nivel cdigo con el patrn Proxy. Cuando un objeto debe ser controlado de alguna manera, ya sea por simple control de acceso o por estar en un sitio remoto o por ser muy pesado y se quiera limitar su uso, es ideal utilizar este patrn.Se realizar un ejemplo de un proxy remoto: la finalidad es que nuestra aplicacin guarde datos en un servidor remoto, pero vamos a impedir se la aplicacin se conecte todo el tiempo, sino que aproveche a guardar todo cuando se encuentre conectada. Caso contrario guardar en el disco duro local la informacin hasta que sea el momento adecuado.

Hasta ahora se tienen 2 formas de guardar: en el disco y en el objeto remoto que necesita conexin. Ambas formas implementan IGuardar. Vamos a crear un sencillo proxy para que se fije si en ese momento hay conexin para aprovecharla y si no hay conexin que guarde los datos en el disco momentneamente.

20