Ingeniera del Software II Curso 2005/2006 Cuaderno de discusiones de Patrones de Diseo: Preguntas y respuestas de la lista de discusin de la asignatura

Este cuaderno contiene las preguntas y respuestas de la lista de discusin (http://servidor/mailman/listinfo/isw2-dist) de la asignatura con algunos comentarios de los profesores.

ndice
Boletn 3.1: Introduccin a los Patrones de Diseo.......................................................... 3 Boletn 3.2: Patrones de Asignacin de responsabilidades (GRASP)............................ 12 Boletn 3.3.1: Faade y Template Method ..................................................................... 18 Boletn 3.3.2: Patrones Factory ...................................................................................... 26 Boletn 3.3.3: Strategy y Adapter ................................................................................... 29 Boletn 3.3.4: Decorator ................................................................................................. 32

Boletn 3.1: Introduccin a los Patrones de Diseo

Cuestin 1: Enuncie las diferencias entre modelos de anlisis y diseo 1) El modelo de anlisis es un modelo conceptual cuya parte esttica est definida por diagramas de clases y cuya parte dinmica por diagramas de secuencia,..., mientras que el diseo aunque tambin se representa mediante diagramas de clases estos estn orientados a la implementacin. 2) En primer lugar los modelos de anlisis tratan de definir cual es el problema a solucionar, mientras que el objetivo de un modelo de diseo es indicar cmo se va a solucionar este problema, es decir, construir una solucin para el problema del anlisis. Ambos utilizan diagramas de clases, pero en los modelos de anlisis las responsabilidades de qu clase hace cada cosa para solucionar el problema no aparece. 3) Los modelos de anlisis son modelos conceptuales que representan la situacin del mundo real que se quiere sistematizar: Modelo esttico de clases (diagrama de clases), modelo dinmico (casos de uso, diagramas de secuencia) y modelo funcional (diagramas de actividad). Los de diseo son modelos para la implementacin: Principios GRASP, PPDD,... Todos dais la definicin de ambos modelos, pero no sus diferencias. Los modelos de anlisis muestran conceptos del mundo real, mientras que los de implementacin introducen conceptos artificiales que son necesarios por usar una implementacin orientada a objetos. Las implementaciones orientadas a objetos permiten asignar responsabilidades (mtodos) a conceptos que en el mundo real no seran activos y por tanto, capaces de realizarlas. Esta es otra de las diferencias: en los modelos de clases de anlisis los objetos no tienen responsabilidades, mientras que en diseo s. Adems, dado que en la mayora de los casos hay que aadir conceptos artificiales para conseguir un buen diseo, los modelos de clases de anlisis suelen tener menos clases que los de diseo.

Cuestin 2: Qu factores motivaron la aparicin de los patrones de diseo? 1) Existen a la hora de disear la solucin a un problema una serie de dificultades que reaparecen de una manera recurrente y que eran tradicionalmente solucionados individualmente por cada diseador. Esta manera de actuar haca que el conocimiento no fuera compartido de una manera clara y exitosa, obligando a cada nuevo diseador a reinventar la rueda tratando de buscar solucin a problemas ya superados anteriormente por otros. Para paliar esta situacin surgen los patrones de diseo, una forma efectiva de comunicar recetas exitosas probadas suficientemente como vlidas para resolver estas dificultades.

Correcto 2) La necesidad de que los diseos fuesen mas reutilizables, fciles de modificar, comprender y usar, mas robustos y mas eficientes. Esa necesidad exista y existe, pero no es la principal motivacin. 3) Adems de los mencionados anteriormente por los compaeros, otro factor fue la necesidad de transmitir conocimiento debido a que en el diseo la experiencia es muy importante y se observo que se utilizaban recetas para los problemas habituales para no estar reinventando la rueda continuamente. Por lo que surgieron como una forma de poder transmitir dichas recetas. Correcto Cuestin 3: Cmo define un patrn de diseo un problema? Y la solucin? 1) En los patrones de diseo el problema aparece definido en el campo "intencin" (aparece una breve resea sobre qu resuelve) y en "motivacin" (En donde aparece un ejemplo concreto en el que la aplicacin del patrn de diseo resuelve el problema planteado). La solucin aparece como un diagrama de objetos (en el apartado "estructura") que resuelven el problema que se quiere tratar de una manera general, permitiendo generalizarlo a las condiciones del problema actual (recogidas en el anlisis). Aunque los patrones de diseo deben ser casi independientes de la implementacin se dan pistas y ayudas sobre cmo implementar la solucin aportada. 2) En la plantilla de descripcin de la GOF los problemas vienen definidos principalmente por los puntos: 2. Intencin: frase corta que responde a qu hace y qu resuelve 4. Motivacin: un escenario que ilustra como el PD resuelve un problema 5. Aplicabilidad: otras situaciones en las que resulta aplicable el PD concreto Y la solucin a su vez se encuentra definida por los puntos: 6. Estructura: diagramas de clases 7. Participantes: responsabilidad de cada clase participante 8. Colaboraciones: diagrama de colaboracin y/o de secuencias 9. Consecuencias: ventajas e inconvenientes 10. Implementacin: dificultades, tcnicas y trucos a tener en cuenta al aplicar el PD

3) Problema es como "algo" que se repite continuamente y en diferentes contextos Creo que preguntan esta definicin porque los "problemas" definidos en los patrones no son siempre problemas. Es decir, creo que los patrones no resuelven problemas como tales, simplemente hacen que no aparezcan problemas debidos a un mal diseo, aplicando para ello la experiencia de muchos diseadores.

Tienes razn en parte. Es cierto que la idea es intentar evitar problemas, pero realmente si identifican un problema. Por ejemplo, el problema de tener un cdigo repetido en varios sitios pero presentando pequeas diferencias (para el caso del template method). Lo importante aqu es que la definicin dada es general (con un nivel de abstraccin alto). Esto facilita su reutilizacin, es decir aumenta la probabilidad de poder aplicarlos. Adems, son ms fciles de entender por no proporcionar detalles de soluciones concretas que solo desviaran la atencin hacia detalles poco reutilizables. Con respecto a la solucin, entre otras cosas se propone un diseo genrico (diagrama de clases), que puede ser adaptado a cada caso (esto lo ejemplificamos en clase con los patrones de costura y los ajustes que se le hacan). Solucin son los pasos a seguir, como una especie de receta para resolver un problema. Ms que pasos a seguir, yo lo veo como una serie de ideas que debes tener claras para aplicarlas en caso de ser necesarios. De acuerdo en esto (hay que conocer las ideas para poder aplicarlas). Pero debes ser capaz de llevar estas ideas a un diseo (diagrama de clases). Lo de las ideas estara ms en concordancia con los GRASP, no tanto con los patrones. Aunque repito, en los dos casos esas ideas o principios hay que manejarlos.

Cuestin 4: Qu caracterstica(s) de los patrones de diseo facilitan su reutilizacin? 1) Pues que suelen ofrecer soluciones a problemas recurrentes (suelen aparecer mucho) y estos son solucionados de una forma abstracta, por lo que "puede utilizarse un milln de veces sin hacer dos veces lo mismo" Correcto, pero cul es la caracterstica? 2) Para empezar la solucin descrita en los patrones de diseo es una solucin general que ha de ser especificada para poder ser aplicada, con lo que se puede adaptar a muchas situaciones concretas favoreciendo as la reutilizacin. En segundo lugar es digno de resaltar que se presenta una solucin que es (o debe serlo) independiente de la implementacin (se trata de reutilizar conocimiento para resolver un problema, no software). El hecho de que aparezcan reseadas las consecuencias del uso del patrn (ventajas e inconvenientes) y la aplicabilidad (cundo se puede usar), hace que sea posible mejorar el mantenimiento y facilita saber en qu situaciones el patrn ha demostrado ser til para resolver un determinado problema. Perfecto. El punto clave es que sea una definicin general (abstracta). Eso hace que aumente las posibilidades de poder aplicarse.

3) Los patrones de diseo son un par problema/solucin, por tanto la descripcin del problema nos ayudara a saber cuando podemos utilizar un patrn de diseo. Un ejemplo concreto seria el patrn de diseo singleton, segn la plantilla de descripcin de GOF, la aplicabilidad nos dice cuando lo podemos usar. Cuestin 5: A que documentos o modelos se le aplican los patrones de diseo?

1) Se aplican en el diseo a los diagramas de clases. 2) En los patrones de diseo la solucin aparece como una estructura de clases con asignaciones de responsabilidad, por ello se aplica en los diagramas de clases en la etapa de diseo (la asignacin de responsabilidades es una de las tareas ms importantes del diseo). Se aplica tanto a los diagramas de clase de anlisis (justo al comenzar la fase de diseo), como a los diagramas de clases de diseo para mejorarlos/aumentarlos, y a al cdigo de aplicaciones existentes a la hora de refactorizarlo para mejorar su diseo. Cuestin 6: Es posible aplicar un patrn de manera aislada, es decir, sin tener en cuenta ningn otro? Es habitual hacerlo? 1) S es posible aplicar un patrn de forma aislada (pero siempre tenemos que tener en cuenta los principios evaluativos), como ejemplo podemos encontrar el ejemplo de los montaditos del patrn template method descrito en clases de teora que no necesitaba de otro patrn. Sin embargo, no es habitual que los patrones de diseo sean aplicados de forma aislada, es por ello que existen relaciones entre estos las cuales son descritas en sus plantillas de descripcin. 2) Bueno, como posible es posible, por qu no bamos a poder aplicar un patrn singleton nicamente? O un patrn faade? Sin embargo esto no es lo habitual. Depender del problema a tratar y la complejidad de ste. Sin embargo hay que resear que existen relaciones entre los distintos patrones e incluso en la plantilla de la Gang of Four aparece un apartado para "patrones relacionados". Perfecto Cuestin 7: Cmo debemos estudiar para ser un buen diseador? 1) La calidad como diseador es adquirida con la experiencia, por lo que no es posible estudiar para ser un buen diseador aunque si podemos adquirir parte de la experiencia de otros diseadores mediante los patrones, por lo que deberamos estudiar patrones de diseo para intentar ser un buen diseador. 2) A da de hoy el buen diseador es un diseador con experiencia, un experto. La nica manera de adquirir experiencia consiste en hacer nosotros mismos los diseos necesarios para conseguirla y sobre todo estudiar los diseos exitosos (y tambin sus fracasos) de diseadores ya expertos. Puesto que el diseo an est en una etapa ms cercana al arte que a unas reglas "fijas" es importante observar el trabajo de los "maestros" antes de poder dedicarnos a hacer buenos diseos por nuestra cuenta. Por supuesto esto pasa por estudiar patrones de diseo y antipatrones.

Bien las dos respuestas. Yo aadira que es importante manejar todos los patrones sin tener que consultarlos y conocer bien las diferencias y similitudes entre unos y otros para poder decidir antes de aplicar cual es la mejor opcin. Cuestin 8: Indique las razones por las que el diseo es una actividad difcil. 1) Para empezar en la etapa de diseo aparecen grandes rupturas entre el mundo real y la analoga que representamos en nuestro diagrama de clases, asignando tareas y responsabilidades a objetos inanimados. Adems pueden existir discrepancias entre el documento de anlisis y lo que realmente se quiere resolver, o puede que los propios requisitos varen a lo largo del proyecto, obligando a modificar el diseo. Por otro lado existe una necesidad de obtener un equilibrio entre los distintos requisitos no funcionales que aparecen en el documento de anlisis. Todo esto, unido a la situacin planteada en la repuesta a la pregunta anterior en la que se trataba la importancia de la experiencia y el estado cercano al arte del diseo, hace que la experiencia sea un valor realmente decisivo a la hora de conseguir un buen diseo. Perfecto Cuestin 9: Cundo se debera empezar a tener en cuenta los requisitos no funcionales? Cuanto antes. Los requisitos no funcionales son complicados de manejar y encajar en el diseo (nmero de accesos concurrentes a una base de datos, tiempo medio de acceso,...) por lo que se deben intentar resolver cuanto antes. Si bien esto es lo ideal, no es lo habitual. Deberamos aadir que esto es as debido a que intentar cumplirlos cuando el diseo esta avanzado es muy complicado o imposible.

Cuestin 10: Discuta sobre la madurez de la Ingeniera del Software respecto de las ingenieras clsicas y otras profesiones. 1) Para empezar viendo las respuestas a las preguntas 7 y 8 se pone de manifiesto la etapa de inmadurez en la que est en estos momentos la ingeniera del software en cuanto a la etapa del diseo se refiere. Aunque los patrones de diseo surgen precisamente para dotar de mayor madurez a la ISW an no se ha conseguido eliminar completamente la situacin actual en cuando al diseo se refiere, casi ms cercana al arte que a otras ingenieras. A pesar de todo poco a poco se dan los pasos necesarios para mejorar la situacin.

Sin embargo en otros aspectos que caen tambin dentro del mbito de la ISW los pasos conseguidos hacia una etapa de madurez plena son ms espectaculares (Vase planificacin, costes y otros aspectos estudiados en ISW3). OK. Animo a que el resto de alumnos hicierais el esfuerzo de pensar sobre esto.

Cuestin 11: Por qu se le da tanta importancia al nombre en los patrones de diseo? Qu relacin tiene esto con la actividad realizada en esta fase? 1) El nombre del patrn debe dar una idea primera de qu hace, qu se consigue al aplicar el patrn. Adems, tal y como se puso de manifiesto en la primera parte de la asignatura, la creacin de un vocabulario propio y ajustado a los conceptos es vital para saber exactamente a que nos referimos. Por ello es necesario que el nombre identifique al patrn sin posibilidad de equivocaciones (q no haya dos patrones con el mismo nombre que hagan cosas distintas). 2) El nombre de los patrones de diseo tiene como fin la identificacin univoca y general del mismo, con el fin de crear un vocabulario comn evitando tener que describir continuamente la idea de dicho patrn (es decir, por ejemplo la palabra Singlenton para los diseadores es equivalente a todos los puntos de la plantilla GOF de este patrn (diagramas de clase, inconvenientes, patrones asociados, etc.) as al solo decir el nombre ya nos estamos refiriendo a todo lo anterior) Perfecto... Es decir, facilita la comunicacin entre los diseadores. Cuestin 12: Qu ventajas puede tener el Singleton cuando hay muchos desarrolladores? Evita que alguno de los diseadores que no conozca bien esa parte del diseo cree varias instancias de una clase.

Cuestin 17: Enuncie el principio de Hollywood y explique cmo se aplica esta metfora a los frameworks y bibliotecas 1) En una biblioteca, la forma de comunicarse con la aplicacin que la utiliza consiste en esperar a que algn mtodo de alguna aplicacin haga uso de alguno de los mtodos u objetos que sta proporciona en alguno de sus algoritmos. Un framework sigue el llamado principio de hollywood "nosotros te llamaremos" lo que viene a significar que para comunicarse con la aplicacin que lo usa proporciona una interfaz con una serie de prototipos que el usuario debe implementar porque sern invocados por el framework en alguno de sus algoritmos. Es decir, son las clases del framework las que usaran las de la aplicacin en lugar de ser al revs como en las bibliotecas. Perfecto

2) Bien, tengo clara lo que es la idea de biblioteca, que es un conjunto de clases para ser reutilizados, que usamos en nuestra aplicacin. Es decir, nuestra aplicacin llama a los mtodos de la biblioteca. Sin embargo, el concepto de framework no lo tengo claro del todo. Cuando lo veo en las prcticas lo entiendo, en el caso de Login. Pero en la teora dice que es un "Conjunto de clases parcialmente funcional (no es una aplicacin) para un dominio de aplicacin" Que es un dominio de aplicacin? Y que es lo que le falta al framework para ser aplicacin? Tampoco tengo claro lo del principio de Hollywood en relacin al framework cuando decimos que "el framework llama a mi cdigo".

Un framework propone un diseo para una aplicacin completa (muchas clases) en la que se dejan "huecos" para que el usuario pueda incluir sus propias clases y adaptar el resultado a sus requerimientos. Es cierto que el framework adems de un diseo proporciona una implementacin. Lo importante de un framework es que no tenemos que cambiar ni una sola lnea de cdigo para incluir las clases que necesitamos para nuestra aplicacin gracias a que siguen el principio de hollywood:"no me llames, yo te llamo". Esta es la razn por la que los patrones template method y factory method son tan adecuados para los frameworks, pues en los dos se proporciona el cdigo donde se llama a los mtodos (en el mtodo plantilla se llama la los mtodos hook o en el mtodo que llama al create) de las clases que se aaden al framework.

Cuestin 18: Indique la diferencia entre idiom y patrn de diseo; discuta sobre las situaciones en las que ambos pueden confundirse. 1) Un idiom es un patrn a bajo nivel sujeto a un lenguaje de programacin concreto mientras que los PPDD no estn sujetos a ningn lenguaje de programacin, estos pueden llegar a confundirse cuando la solucin de un determinado patrn esta muy sujeta o vinculada a un lenguaje de programacin. Un idiom no tiene por que ser de bajo nivel. Iterator no lo es. Lo que realmente los distingue es que el idiom supone una forma especial de escribir el cdigo. Aun as, en muchas ocasiones no existe una frontera clara y es cuestin de opiniones el caracterizar algo como patrn o idiom. 2) La diferencia radica en que un idiom resuelve un determinado problema en un lenguaje de programacin concreto (copiar cadenas en c, por ejemplo), mientras que la solucin proporcionada por el patrn de diseo est alejada de la implementacin en un lenguaje concreto. A veces puede confundirse porque los patrones de diseo a veces aparecen muy ligados a la implementacin y se incorporan como caractersticas de los lenguajes de programacin.

Bien lo que dices. Un ejemplo de esta situacin es el patrn/idiom iterator: propone un diseo determinado, pero adems supone una forma de escribir el cdigo necesario para recorrer una coleccin.

Cuestin 19: Enuncie los antipatrones que conozca junto con una breve descripcin de los mismos. De cara al examen solo tenis que conocer los vistos en clase. Aunque no est mal que hagis un poco de investigacin *The blob: Una clase se convierte en una masa informe debido a tener un desorbitado tamao convirtindose en un problema para el mantenimiento y la compresin. - BLob (tambin conocido como God Object): Una clase gigantesca que hace de todo (una amalgama de mtodos) mientras las dems apenas contienen datos, las responsabilidades no estn distribuidas uniformemente.

Son clases que intentan hacerlo todo sin ayuda de otras clases (sin acoplarse con otras clases). Como resultado requieren gran cantidad de mtodos y almacenar mucha informacin. * Poltergeists: Los objetos de una clase tiene un tiempo de vida muy corto. - Poltergeists: Los objetos de una clase tienen una corta vida (aparecen y desaparecen como un poltergeist) usadas usualmente para pasarle informacin a objetos de otra clase (tpicos nombres de estas clases son manager_xxx o controlador_xxx). Bien esta ltima definicin.

- Copy & Paste: tpico de cuando ests aprendiendo algo nuevo y en lugar de intentar hacerlo t mismo te dedicas a buscar cdigo por Internet, foros, libros o apuntes que copias y utilizas sin llegar a entender realmente para, posteriormente, "adaptarlo" al problema que tienes entre manos. Es normal que se produzca un palimpsesto de distintos estilos, con cdigo superfluo, difcil de mantener, poco eficiente... Aunque lo usen tambin programadores expertos que entiendan el cdigo a la perfeccin (aun siendo suyo), es una mala tcnica. El algoritmo debera ser lo suficientemente genrico como para poder ser utilizado sin ser modificado directamente. Bien - Spaghetti code: Piensa en un plato de espaguetis antes de echarle el tomate. Seras capaz de decir dnde termina un espagueti y empieza otro? Casi imposible. El

antipatrn Spaghetti code hace referencia a algoritmos cuya estructura de control es tan complicada de seguir como la del plato. Tpico de usar gotos y dems. En programacin estructurada es ms complicado (pero recuerdo que con breaks, case, continues, variables estticas y el propio goto en c es fcil hacer algo as). Bien

Boletn 3.2: Patrones de Asignacin de responsabilidades (GRASP)

Cuestin 1: Conocidos los GRASP, qu diferencias observa entre anlisis y diseo? 1) El objetivo en el anlisis consiste en definir de una manera conveniente el problema que se desea resolver. En el diseo se trata de modelar una solucin asignando responsabilidades a las clases. Deberamos aadir: Teniendo en cuenta adems detalles de implementacin y los posibles cambios (variacin/evolucin) que requiera el sistema, es decir, aplicando variaciones protegidas. 2) Pues que en el anlisis la preocupacin era atender a los requisitos mientras que en el diseo se deben tener en cuenta principios como los GRASP Demasiado incompleto.

Cuestin 2: Por qu los objetos asumen responsabilidades que no existen en el mundo real? Qu problema causa esto? 1) Porque los sistemas informticos tienen que realizar funciones que no existen en el mundo real como la creacin de un objeto, el acceso a una base de datos, etc. Cierto, pero incompleto. 2) En el diseo ciertos objetos inanimados se ven obligados a adquirir responsabilidades ajenas a su condicin en el mundo real por la necesidad de creacin de nuevos objetos agregados o controlar ciertos valores o la ejecucin de determinadas tareas que en el mundo real hara una persona o mquina. Estas tareas deben ser asignadas de forma que no se vean afectadas ni la eficiencia, ni el mantenimiento, ni la reutilizacin y adems lleve a un diseo comprensible, lo que obliga a asignar ciertas tareas a objetos inanimados. El mayor problema que esto supone es que la relacin entre el mundo real y la representacin creada en el documento de anlisis y diseo se separan. Correcto.

Cuestin 3: Por qu Larman llama patrones a los GRASP? Qu nombre sera ms adecuado? 1) Larman llama patrones a los GRASP porque la palabra patrn era una buzz-word, algo llamativo y de moda. Pues en vez de patrones hubiera sido ms lgico usar el nombre de principios.

Correcto. 2) Creo que los llama patrones siguiendo el concepto de patrn, ya que los GRASP se aplican a un problema concurrente y aportan una especie de solucin, aunque no es una solucin exactamente, sino mas bien un "consejo" que te permite obtener un buen diseo El nombre mas apropiado seria "principios", ya que como dijimos antes, los GRASPs no permiten obtener una solucin tal cual, sino un diseo bueno indicando una serie de pautas para conseguirlo. Los problemas tratados por los principios son demasiado generales para considerarlos patrones desde el punto de vista GOF. Ver la respuesta 1. 3) Los llama Patrones porque estn expresados o descritos como tales (par problema solucin y dems puntos de la plantilla), pero hubiera sido mas correcto llamarlos principios pues en ellos se basan e intentan darle solucin los dems patrones. No son patrones, puesto que no proporcionan un esquema de solucin basado en una estructura de clases determinada. Ver respuestas anteriores.

Cuestin 4: Qu ventajas tiene enunciar los GRASP si ya eran conocidos? 1) Formalizar su existencia y unificar conceptos evitando as que fuesen transmitidos de forma independiente. 2) Primero de todo darlo a conocer "de verdad", es decir, describirlos de una manera ms rigurosa. Hay que recordar que el diseo an se encuentra en una fase cercan al arte por lo que a pesar de ser principios muy conocidos y aplicados, toda disciplina debe contar con unos rigurosamente descritos y formalizados (que todo el mundo sepa de qu se habla) para poder apoyarse en ellos. En el momento que Larman los introdujo es cierto que eran conocidos, pero conocidos, por as decirlo, casi por ciencia infusa, de una manera inconsciente y natural. Las dos respuestas son correctas pero incompletas. Tendramos que aadir: Que tambin se describen para que no sean reinventados/asimilados/redescubiertos una y otra vez. De esta forma se conocen como un todo y nadie tiene duda de que es un principio y que no lo es. Tambin se evita la definicin del mismo principio de varias formas distintas como ocurra por ejemplo con variaciones protegidas que era definido de varias formas: principio abierto/cerrado, principio de sustitucin de liskov, principio de encapsulacin, no hables con extraos,...

Cuestin 5: Qu es un principio evaluativo? Cules son y cmo se relacionan? 1) Un principio evaluativo es aquel que el diseador debe aplicar cada vez que introduce una modificacin en el diseo.

Hemos visto alta cohesin y bajo acoplamiento. La relacin que tienen ambos proviene de ser principios contrapuestos. Es normal que una clase que presenta un alto acoplamiento presente tambin una baja cohesin y viceversa. Con respecto a la relacin: Es correcto pero es importante tener claro que esto no es siempre as. Es decir, una clase con alto acoplamiento puede tener muy mala cohesin. Lo que ocurre es que por regla general (insisto en que no siempre) cuando intentamos bajar el acoplamiento se produce un empeoramiento de la cohesin si slo aplicamos estos dos principios. Dado que si al intentar bajar el acoplamiento de dos clases aadimos una tercera usando una indireccin y cuidamos la cohesin, esta no tiene que verse comprometida. Un ejemplo de esto sera la aplicacin de un Simple Factory para reducir el acoplamiento entre dos clases. De ah que se tengan que aplicar siempre al hacer un cambio en el diseo. 2) Son principios que son tenidos en cuenta a la hora de evaluar una decisin de diseo. Los principios evaluativos son bajo acoplamiento y alta cohesin. Son principios opuestos por lo que se debe intentar encontrar un equilibrio entre ambos. Cierto, pero incompleto. Ver respuesta anterior. Cuestin 6: Es posible aplicar un GRASP de manera aislada, es decir, sin tener en cuenta ningn otro? Es habitual hacerlo? 1) Yo creo que no, ya que siempre que apliquemos un GRASP estamos tomando una decisin de diseo por lo que debemos tener en cuenta los principios evaluativos, y al aplicar alguno de los principios evaluativos tenemos que tener en cuenta el otro ya que como hemos dicho anteriormente estn directamente relacionados (son opuestos) Correcto. Por ejemplo, al intentar reducir el acoplamiento sabemos que esto nos puede empeorar la cohesin, por lo que tendremos que aplicar indireccin (para mejorar el acoplamiento) y/o fabricacin pura (para mejorar la cohesin) para que el acoplamiento y la cohesin permanezca a un buen nivel. 2) Pues yo dira que no, al ser principios de diseo deben ser tenidos todos en cuenta, no tiene mucho sentido tener en cuenta unos principios y otros no si se desea obtener un buen diseo, claro. No es falso, pero es obvio. Ver comentario anterior. 3) S, siempre que sea un GRASP que no tenga relaciones o dependencias con otros. Cules son estos? No, ya que hay que tener en cuenta varios GRASPs para obtener un buen diseo. Adems, existen GRASPs que, al aplicarlos, afectan a otro GRASP, como por ejemplo, Bajo Acoplamiento y Alta Cohesin pues al quitar responsabilidades a una clase y delegarlas a otra, aumenta el acoplamiento. O viceversa, al eliminar clases para reducir el acoplamiento, las responsabilidades de dichas clases van a otra de las clases con las que estaba relacionada.

Correcto, pero siempre que no uses indirecciones/fabricaciones puras como hemos visto antes Cuestin 7: Cul es la tarea primordial que controlan los GRASP? Por qu es tan importante esta tarea? Por qu no la hemos realizado en anlisis? 1) La tarea primordial es la asignacin de responsabilidades. No es posible definir estas durante la fase de diseo puesto que durante sta tan slo se busca definir el problema a resolver. La tarea primordial es asignar responsabilidades, o lo que es lo mismo, aadir/asignar mtodos a las clases. Con respecto al resto de preguntas: Supongo que cuando dices diseo quieres decir anlisis. Concretando un poco lo que comentas, en el mundo del anlisis se hace un modelo de conceptos (modelo conceptual) en el que existen conceptos inanimados (facturas, productos,...) que no pueden asumir responsabilidades. Al pasar a diseo orientado a objetos esta tarea es primordial para acercar el modelo del mundo real al de la implementacin. En anlisis no se puede hacer puesto que se usan conceptos y no clases de diseo y debido a que los conceptos inanimados no pueden asumir responsabilidades. 2) Describen los principios fundamentales del DOO y la asignacin de responsabilidades, problemas propios de la fase de diseo. Incompleto y casi incorrecto. Ver respuesta anterior. Cuestin 8: Cules son los principios ms importantes a tener en cuenta? 1) Bajo acoplamiento y alta cohesin. Variaciones protegidas tambin es de suma importancia, pues es el que nos gua en decidir cuando el acoplamiento es desfavorable aun siendo no demasiado alto. Cuestin 9: Qu problemas producen los cambios en el diseo y cmo se solucionan segn los GRASP? 1) Los cambios en el diseo de un elemento suelen afectar a otros elementos por ello GRASP propone variaciones protegidas. Cierto, pero muy escueto. 2) Los cambios en el diseo afectan a numerosos objetos pudiendo causar inestabilidad en el sistema si no se tiene en cuenta el principio de variaciones protegidas, que consiste en identificar con antelacin los puntos en los que el diseo podra variar (evolucionar) y actuar de modo que sea posible protegerse de estos. Qu significa protegerse? La idea es aislar esos puntos de forma que cuando se produzca el cambio afecte lo menos posible al resto de clases del sistema.

Cuestin 10: Enuncie los problemas a los que nos lleva la aplicacin desmedida de cada GRASP (algunos de ellos son anti-patrones) y razone la respuesta. Por ejemplo: Aplicar de manera desmedida el principio alta cohesin nos lleva al anti-patrn. . . 1) - Aplicar de manera desmedida el principio experto en informacin nos lleva a tener diseos que aumenten el acoplamiento y la duplicacin de cdigo (pensad en que cada clase se tiene que guardarse a s misma en una BD). Correcto. Tambin puede disminuir la cohesin. - Aplicar de manera desmedida el principio alta cohesin nos lleva al anti-patrn clasesalgoritmos, lo que conlleva un aumento del acoplamiento (si mi clase hace algo excesivamente especfico necesitar otras para llevar a cabo una tarea ms general). Tambin nos puede llevar al antipatrn poltergeist donde los objetos aparecen y desaparecen de manera incesante. - Aplicar de manera desmedida el principio bajo acoplamiento nos lleva al anti-patrn Blob y adems conlleva una disminucin de la cohesin (la manera de bajar el acoplamiento es que se necesiten menos clases para hacer una tarea, con lo que la funcionalidad de esas clases ser traspasada). Correcto. - Aplicar de manera desmedida variaciones protegidas puede llegar a hacer que el coste de proteccin ante esas variaciones sea superior al de modificar un diseo. Correcto. Esto se ilustra con la mxima: "elige tus batallas" - Aplicar de manera desmedida el principio de indireccin puede hacer que tengamos problemas de ejecucin en nuestro sistema Ms que de ejecucin deberamos decir de eficiencia. Adems dificulta el entendimiento y nos acerca al antipatrn poltergeist.

Cuestin 12: Cmo se mide el acoplamiento? Ponga un ejemplo. Acoplamiento es una medida de la fuerza con que un elemento est conectado a, tiene conocimiento de confa en otros elementos. Usualmente se dice que una clase es muy acoplada si tiene muchas relaciones. Ejemplo: sea una clase A con mtodos m1() y m2(), una clase B con mtodos n1() y n2(), una clase C con un mtodo p() y una clase D. cualquier cambios en los mtodos de B o C, afectara a la implementacin de los mtodos de A, por tanto, la clase A est muy acoplada, asimismo sera muy difcil de reutilizar.

Aadir que el acoplamiento puede aparecer de muchas formas: parmetros en mtodos de una clase que son objetos de otra, atributos de una clase que son referencias a objetos de otra, devolver objetos de otra clase en un mtodo y crear variables locales en los mtodos de una clase de objetos que son de otra clase. Lo importante es ver que el acoplamiento se mide entre dos clases y que ste ser desfavorable cuando exista un punto de variacin o cuando el acoplamiento de una clase con el resto sea muy fuerte: mucha utilizacin de objetos de otra clase y/o acoplamiento con varias clases al mismo tiempo. Cuestin 13: Cmo se mide la cohesin? Ponga un ejemplo. Cohesin es una medida de la fuerza con la que se relacionan y el grado de focalizacin de las responsabilidades de un elemento. Un elemento con baja cohesin tiene muchas responsabilidades. Y estas responsabilidades adems estn orientadas a reas funcionales distintas. Es decir, muchos mtodos y que adems estos realizan tareas muy distintas. Sea una clase C con mtodos m1(), m2(), ..., mk(), y algunos de ellos tienen una funcionalidad de acceder por ejemplo, a una BD, entonces se podra delegar la responsabilidad de acceso a la BD a otra clase denominada AccesoBD. Esto no es un ejemplo de alta cohesin o baja, es una forma de solucionar. Alguien nos manda un ejemplo de las dos situaciones que no sea el de clase?

Cuestin 16: Enuncie y razone las ventajas del principio "Controlador". - Aumenta las posibilidades de reutilizacin. Al delegar las responsabilidades de controlador a otra clase, si cambia p.e. la librera de la interfaz grfica, no hay que modificar el cdigo de la clase cliente, slo el del controlador. - Razonamiento sobre el estado de los casos de uso. Al estar el cdigo del controlador separado de la aplicacin, se manejan las operaciones de sistema en la lgica de la aplicacin y no en la interfaz de usuario (arquitectura de 3 capas). Esto permite un seguimiento de los pasos en el caso de uso para verificar si es vlido o no. Faltan cosas que estn detalladas en los apuntes. Alguien nos las manda y nos las explica?

Boletn 3.3.1: Faade y Template Method

Cuestiones generales Cuestin 1: Cul es el principal objetivo del patrn Faade? 1) Crear una interfaz unificada para un conjunto de interfaces que ofrece un determinado subsistema, hacindolo mas fcil de usar. 2) Abstraer la funcionalidad de un sistema complejo de usar para simplificar el uso de ste a las clases clientes que deban usarlo, actuando a modo de interfaz entre el sistema y los clientes, pero sin hacer inaccesibles las clases del sistema. Las palabras clave son: Simplificar pero para uno de los usos habituales del subsistema (no para cualquier caso)

Cuestin 2: Cul es el principal objetivo del patrn Template Method? 1) Abstraer un algoritmo definiendo su esqueleto, de modo que la parte fija de stos aparezcan implementadas en una clase padre y las partes variables aparezcan implementadas en las clases hijas que lo concretarn adaptndolo para la solucin de un problema concreto. Bien. 2) Presentar una serie de plantillas de algoritmos, dichas plantillas constan de una parte fija y una parte que deben implementar cada una de las clases cliente que quieran utilizar las plantillas. De esta forma logramos reutilizar cdigo y favorecemos el mantenimiento y entendimiento de los distintos algoritmos involucrados. No son varias plantillas, sino solo una. Cuestin 3: Qu ventajas ofrece el patrn Faade? 1) Abstrae a la clase cliente de la complejidad del subsistema que se desea utilizar, adems elimina el acoplamiento de la clase cliente con el subsistema puesto que ahora el acoplamiento se dirige con la clase Fachada (in direccin). Por ltimo favorece la divisin en capas y no impide que las clases clientes puedan hacer un uso directo del subsistema. 2) - Simplifica el uso de un sistema complejo, abstrayendo la funcionalidad de ste. - favorece la definicin de distintas capas para usar el sistema. - desacopla las clases cliente de las clases del sistema (indireccin mediante la clase fachada), As mejora la portabilidad y aade proteccin de las clases clientes ante cambios en la implementacin del sistema tras la fachada.

Correcto los dos, pero hay que tener en cuenta que al no impedir el uso directo del subsistema, el desacoplamiento no es total y los cambios en el subsistema s pueden afectar.

Cuestin 4: Qu ventajas ofrece el patrn Template Method? 1) Reutilizacin de cdigo, no es necesario volver a implementar aquellos mtodos que son exactamente iguales en varias clases, adems aquellos que varan, las partes fijas tampoco es necesario volver a implementarlas solo aquellas partes que son distintas, esto a su vez hace que sea mas fcil su mantenimiento, depuracin y entendimiento. Por ultimo es muy til en la creacin de bibliotecas y frameworks. 2) - el comportamiento comn de varias clases se implementa una nica vez - mejora la mantenibilidad - es til para la creacin de bibliotecas y frameworks Correcto los dos.

Cuestin 5: Qu GRASP(s) se aplican en el patrn Faade? 1) Indireccin y controlador, este ultimo ya que los controladores suelen actuar como puntos de entradas (fachadas) de la capa lgica. Por su puesto estara tambin relacionado con los principios alta cohesin y bajo acoplamiento. Una puntualizacin: La cohesin de las fachadas suele ser baja. 2) - Indireccin (introducimos la clase fachada para bajar el acoplamiento) - Controlador (separa la lgica del sistema de la interfaz que proporciona la fachada, que adems suele ser comn a todos los clientes usando el patrn Singleton) Correcto. Cuestin 6: Con qu principio(s) est relacionado el patrn Template Method? 1) esta relacionado con el principio de hollywood, es decir "no nos llames, nosotros te llamamos", este es el mismo principio que se aplica en los frameworks ya que al igual que en aquellos, se dejan por definir algunos mtodos (mtodos hook), de manera que despus es el cliente el que debe definirlos en su aplicacin concreta. 2) - Estrategia (aunque cambia todo el algoritmo en lugar de una parte que se concreta) - Fabricacin pura (la clase fachada no representa ninguna clase del dominio del problema, es fabricacin de la mente y est creada especficamente para un fin concreto).

Estrategia no es un principio y la fabricacin pura tiene como objetivo mejorar la cohesin, por lo que no seran ninguno de estos. Lo correcto es variaciones protegidas y dentro de este, el principio de hollywood Qu relacin tiene este principio con los frameworks? La relacin proviene por la forma de llamar a los mtodos hook. Puesto que el algoritmo aparece creado en la clase padre, es sta la que se encarga de llamar a los mtodos de las clases hijas que aaden la funcionalidad necesaria para que el algoritmo pueda ejecutarse (segn el principio de Hollywood) 3) -->> No s si se refiere a principios de los GRASP, pero yo creo que se refiere al Principio de Hollywood. Est relacionado con dicho principio ya que la clase padre contiene los mtodos gancho, los cuales son definidos en las clases hijas. Y es la clase padre la que llama a dichos mtodos cuando los necesita, lo q lleva al principio de hollywood. Correcto, es el principio de Hollywood, pues es el mtodo plantilla el que llama a los mtodos incluidos en las clases hijas. De esta forma, la clase padre estara dentro del framework y las clases hijas fuera.

Cuestin 7: Con qu principio(s) est relacionado el patrn Faade? 1) adems de los enunciados anteriormente, estara relacionado con la ley/principio de Demeter, que dice "no hables con extraos", puesto que las clases cliente que hicieran uso de la fachada usaran solo sus mtodos, nunca nos encontraramos con encadenamientos de la forma: obj.getAtr1().getAtr2().metod(). Este principio pertenece a variaciones protegidas. 2) Adems de los indicados en la respuesta 5 (indireccin y controlador), yo aadira que tambin est relacionado con el patrn Bajo acoplamiento (entre las clases cliente y el sistema) y con Variaciones protegidas (la clase cliente se protege ante variaciones del sistema abstrado por la fachada si los clientes usan la fachada) Correcto, pero teniendo en cuenta que la fachada no evita el uso directo del subsistema. Por lo que el desacoplamiento no es total. 3) Tambin el patrn Alta cohesin, pues las responsabilidades del cliente no han cambiado, sin embargo, la fachada tiene muchas responsabilidades La cohesin de la fachada suele ser baja al aglutinar todas las responsabilidades de un subsistema. Nunca alta. Cuestin 8: Es posible aplicar los patrones tal y como se definen en los libros? Por qu? Ponga un ejemplo.

1) En principio si seria posible, as vemos como en la practica 4 de la asignatura se aplicaba el patrn Singleton exactamente igual a como se describa en su plantilla, sin embargo no es lo normal, as pues muchas veces al adaptarlos a la situacin concreta ya sea a causa de que se use junto con otros patrones, a causa de la implementacin concreta, o para que se cumplan los diversos requisitos tanto funcionales como no funcionales. 2) El ejemplo propuesto en clases de teora se basa en el patrn template method, que habla de que son las clases hijas (mediante mecanismos de herencia) las que concretizan el algoritmo y, sin embargo, en el caso de implementar la interfaz Comparable de JAVA slo tendran que implementar el mtodo compareTo sin usar mecanismos de herencia, siendo el mtodo plantilla el mtodo sort de Java.util (un mtodo esttico) Correcto. Hay numerosas ocasiones en la que no es posible aplicar el patrn como es definido tericamente. Un ejemplo es el sort de colecciones de JAVA. La conclusin es que hay que manejar bien la idea y esencia de los patrones para ser capaces de adaptarlos a la situacin concreta donde tengamos que usarlo teniendo en cuenta el diseo actual y los requisitos, tanto funcionales como no funcionales.

Cuestiones especficas Cuestin 9: Indique las dos opciones para implementar un mtodo gancho (hook) en la clase base de un mtodo plantilla. 1) No estoy seguro de que se trate de esto, pero supongo que el primer mtodo es el tpico que se comenta de declarar en la clase padre un mtodo abstracto que se usa en el mtodo plantilla, de modo que las clases hijas sean las que lo concreten e implementen. El segundo mtodo sera el comentado en la cuestin 8, que definira el mtodo compareTo como mtodo Hook del mtodo plantilla sort de java.util, es decir, usara un mtodo esttico que sera el mtodo plantilla definido en alguna clase, poniendo como requisito que objetos con los mtodos que concreten el algoritmo implementen una determinada interfaz (que contendr los mtodos que se usarn de enganche). Este segundo caso no es un template method tpico. Se os ensea para que veis que los patrones no se pueden aplicar siempre como estn definidos en los libros. La respuesta correcta para el segundo tipo de hook es la 3) y 4). 2) Por un lado podemos declarar el mtodo de forma abstracta de manera que fuera despus el cliente que usara el mtodo plantilla el encargado de implementarlo. Por otro lado podramos darle una implementacin por defecto de manera que el cliente podra redefinir dicho mtodo, pero al contrario que suceda en el caso anterior, ya no seria obligatorio, en este caso evidentemente el mtodo hook no podra ser declarado como abstracto.

En esta segunda forma de definir un mtodo hook esta mi duda, en la practica 6 se declaro un mtodo hook de esta forma en concreto era el mtodo getStrLog que devolva una cadena con la forma en la cual se haba realizado el login, la duda esta en

que no se si verdaderamente podramos llamar a este tipo de mtodos, mtodo hook puesto que en la definicin del patrn se dice que un mtodo hook debe de ser abstracto pues no debe de tener implementacin alguien podra responder?? 3) Yo tengo en mis apuntes que s se puede. Seran las dos formas de poder definir un mtodo hook (mtodo abstracto o con implementacin por defecto). Correcto, esas son las dos formas. 4) puede ser el ejemplo propuesto en la pregunta anterior, es decir por un lado tendramos los mtodos hook definidos tal y como viene expresado en el patrn es decir como mtodos abstractos, la segunda seria darles una implementacin por defecto, y despus el cliente si lo desea podra cambiar dicha implementacin redefiniendo el mtodo, en este caso evidentemente el mtodo hook no se podra declarar como mtodo abstracto. Correcto tambin. Cuestin 10: Indique que modificadores (public, protected, private, abstract, final) deberan aplicarse a los distintos mtodos implicados (el mtodo plantilla, los mtodos hook) en el patrn template method. 1) El mtodo plantilla debe ser final (pues nadie debe ser capaz de modificar el algoritmo en este patrn) y pblico/privado/protegido dependiendo de las necesidades. Aunque por regla general suele ser publico. Los mtodos hook deben ser protegidos (no visibles desde fuera, pero visibles por sus hijos) y abstractos (la funcionalidad deben concretarla los hijos que los hereden). Abstractos no siempre. Vase la pregunta anterior. 2) Sobre el o los mtodos plantillas, aplicaramos el modificador final ya que no seria correcto que una clase hija redefiniese la parte fija del algoritmo. Por otro lado sobre los mtodos hook en primer lugar debemos de aplicar el modificador protected puesto que este tipo de mtodos solo deberan ser llamados desde las clases hijas no desde el cliente, tambin habra que aplicar el modificador abstract para aquellos en los cuales no se diera una implementacin por defecto como veamos en el apartado anterior Perfecto Cuestin 11: Una vez aplicado el patrn Faade, cmo podemos usar las clases del subsistema que la fachada oculta? 1) La aplicacin del patrn Fachada no implica en ningn caso que se impida el acceso a las clases del subsistema. Se puede seguir accediendo al subsistema de manera normal (el ejemplo que se me ocurre es la relacin entre JFace y el SWT para creacin de interfaces en java).

2) El patrn faade no impide de ninguna forma el uso de las clases del subsistema, este patrn simplemente propone una interfaz para dicho subsistema con las ventajas comentadas anteriormente. Por lo tanto podemos usar las clases y mtodos del subsistema de manera normal, es decir de la misma forma que si la fachada no existiese. Correctas las dos respuestas. Cuestin 12: Cmo podemos enganchar una nueva funcionalidad (clase o mtodo) usando un mtodo plantilla? Quin es el encargado de llamar/usar esta nueva funcionalidad? 1) Creando una nueva clase que extienda de la clase plantilla concreta, de modo que en esta nueva clase se implementase los mtodos hook con la nueva funcionalidad que se le quieren dar, el encargado de llamar a estas clases seria el mtodo plantilla siguiendo el principio de hollywood Correcto Cuestin 13: Es posible tener una clase con un mtodo plantilla que no sea abstracta? 1) No, el mtodo plantilla slo define el esqueleto del algoritmo, las partes fijas s aparecern especificadas, pero para completar la funcionalidad las partes variables del algoritmo deben aadirla las clases hijas, por tanto la clase con mtodo plantilla har uso de mtodos abstractos (sin implementar) en el mtodo plantilla. Automticamente esto convierte a esa clase en abstracta. Incorrecto, ver respuesta 2) 2) Si, el caso visto anteriormente sobre que se de una implementacin por defecto de todos los mtodos gancho. Si damos implementacin por defecto de todos los mtodos gancho la clase no tiene que ser abstracta. Cuestin 14: Cmo aade una fachada nueva funcionalidad al subsistema? Es correcto aadir nueva funcionalidad?

1) No creo que sea correcto puesto que la fachada debera abstraer la funcionalidad ya existente en el subsistema sirviendo como "interfaz simplificada" de ste, no aadir nueva funcionalidad. 2) La forma de que una fachada aadiese nuevas funcionalidades es tan sencilla como crear nuevos mtodos en la fachada para que implementasen dichas funcionalidades, sin embargo esto no seria en absoluto correcto puesto que las fachadas son creadas para facilitar el uso de un subsistema no para crear nuevas funcionalidades, es decir, todos los cosas que pudisemos hacer con la fachada deberamos ser tambin capaces de hacerlas utilizando directamente el subsistema.

Correctas las dos respuestas. Hay que tener en cuenta que combinar la funcionalidad que ofrece el subsistema (varias llamadas a mtodos de distintas clases) para simplificar no podra considerarse aadir una nueva funcionalidad. Cuestin 15: Es obligatorio tener una fachada por subsistema? 1) Depende de la situacin, si los subsistemas son lo suficientemente complejos puede que sea viable pues el objetivo de este patrn es simplificar el uso del subsistema tras la fachada al cliente. Realmente no es obligatorio tener ni una, ni varas. Como bien dices, depende de la situacin. 2) No, por un lado podemos perfectamente no definir ninguna fachada para un subsistema, y por otro podemos definir varias, esto ultimo es muy interesante ya que esto permite dividir el subsistema en varias capas, de manera que cada capa encapsulara un conjunto de funcionalidades, generalmente dichas funcionalidades estaran relacionadas entre si (ya se sabe que por regla general se busca la alta cohesin) Correcto, pero las fachadas casi nunca mejoran la cohesin, como se ha visto antes. Cuestin 16: Adems de simplificar el uso del subsistema, qu otra ventaja proporciona una fachada? 1) Separa el cliente del sistema que va a usar, consiguiendo as proteccin ante variaciones de la implementacin interna del cliente, mejora la portabilidad, baja el acoplamiento entre los clientes y el sistema y favorece la creacin de niveles en el sistema. 2) por un lado la divisin del subsistema en varias capas, por otro eliminar (o reducir) el acoplamiento entre las clases cliente y el subsistema Bien las dos respuestas, pero reincido en que el desacoplamiento no es total.

Cuestin 17: Cmo se puede implementar un paso opcional del mtodo plantilla sin necesidad de usar una instruccin if? 1) En el esqueleto del mtodo plantilla usar un mtodo abstracto que ser el paso Opcional, que deber ser concretado en la clases hijas, pero, en stas se implementar o no, dependiendo de si se quiera o no usar ese paso opcional. Incorrecto. Es mejor la segunda respuesta. 2) en el mtodo plantilla hacer una llamada a un mtodo, a dicho mtodo se le dar un cuerpo vaco en la clase plantilla, de manera que si en la clase cliente se desea utilizar el paso opcional se le dar una implementacin al mtodo, en caso contrario se dejara tal cual. Correcta la segunda respuesta. De hecho esto es bastante comn, pues evita que el usuario del framework tenga que incluir mtodos que no necesita con una

implementacin vaca. Lo que se hace es aadirlos en la clase padre con una implementacin por defecto vaca.

Cuestin 18: Una clase que contenga un mtodo plantilla con muchos mtodos abstract obliga a las subclases a realizar gran parte de la implementacin del algoritmo. Es esto deseable? En qu situaciones puede ocurrir esto? Cmo podemos evitarlo? 1) Depender de la situacin y del control que se le quiera dar a cada usuario. Por ejemplo existe el patrn Estrategia precisamente para que el cliente cambie todo el algoritmo en lugar de tan slo una parte. No es deseable, pues esto implica un mal diseo. Muy bien la idea de usar estrategia en estas situaciones. 2) Evidentemente esto no es nada deseable, puesto puede llegar el caso que fuera preferible que la clase no usara la plantilla y realizara una implementacin del algoritmo de una forma directa, esto sucede en caso de que la plantilla no tuviera muchas partes fijas, por lo que la mayor parte son llamadas a mtodos abstractos. Por ultimo una posible solucin seria dar una implementacin por defecto a dichos mtodos de manera que no fuera necesario definirlos todos, lo cual ahorrara trabajo al cliente La mejor solucin sera usar estrategia en estos casos.

Boletn 3.3.2: Patrones Factory

Cuestiones generales Cuestin 1: Cul es el principal objetivo del patrn Factory Method? Y del idiom Simple Factory? Deje clara la diferencia entre los dos patrones. En los dos casos consiste en desacoplar la creacin de objetos de las clases que tiene que utilizarlos. En ambos casos esto es debido a que el conjunto de productos a crear no es fijo y representa por tanto un punto de variacin. El objetivo de simple factory es nicamente desacoplar una clase de la creacin de objetos, El objetivo de factory method es: Definir una interfaz para crear objetos de tipo genrico permitiendo a las subclases decidir qu tipo de objetos concreto crear . Es el mismo que en simple factory slo que se ampla para proporcionar un diseo en el que los productos se pueden aadir sin necesidad de retocar el cdigo existente, es decir, desacopla la creacin de objetos facilitando la creacin de frameworks. Aplicando variaciones protegidas, y dentro de este principio, el principio de hollywood. Cuestin 2: Qu tipos de acoplamiento resuelve Simple Factory? Acoplamiento en la creacin de objetos Cuestin 3: Qu relacin existe entre el patrn Template Method y el patrn Factory Method? Son iguales, slo que en Factory Method el mtodo gancho se encarga de crear objetos y es llamado create. Cuestin 4: Qu ventajas ofrece el patrn Factory Method en referencia a la utilizacin/creacin de frameworks? 1) Que ofrece mtodos abstractos en la clase padre (actan de mtodos de enganche) que se definen en cada una de las subclases concretas, y son invocados desde la clase padre o interfaz (depende de la implementacin que hayamos escogido), lo cual es el principio de Hollywood. Los mtodos gancho en el caso de factory method es el create y hay que puntualizar que no tiene que ser abstracto forzosamente, podemos proporcionar una implementacin por defecto. Deberamos aadir tambin, que al definir una interfaz comn para todos los productos a crear, tambin aseguramos que estos cumplan con ella y puedan aadirse al framework sin retocar el cdigo del mismo. Cuestin 5: Qu GRASP(s) se aplican en el idiom Simple Factory?

En primer lugar variaciones protegidas: - Al aadir una interfaz comn para el punto de variacin que es representada por el producto abstracto. Esto permite proteger al cliente de los cambios en el uso de los productos, pero no en su creacin - Tambin aplicamos indireccin para desacoplar la clase cliente de la creacin de objetos Cuestiones especficas

Cuestin 6: Al usar el idiom Simple Factory estamos pasando el problema de la creacin a otra clase, no lo evitamos. Qu se consigue con esto? 1) Eliminar el acoplamiento entre la clase cliente y las clases concretas, a cambio de pasar dicho acoplamiento entre la clase fbrica y las clases concretas. Correcto. As, si cambiamos los productos solo habr que cambiar el cdigo de la fbrica y no el de todas las clases que los usen. Cuestin 8: Cul es la ventaja del Factory Method cuando se tiene un nico producto concreto? 1) Que al existir una fbrica entre el cliente y el producto concreto, el cliente no tiene acoplamiento con el producto concreto, no tiene que conocer su implementacin y lo protege de posibles variaciones Correcto, pero habra que aadir que proporciona las ventajas derivadas de un framework: nos permite aadir nuevos productos y nuevas fbricas concretas de manera transparente (sin tener que modificar el cdigo del framework) Cuestin 9: Qu diferencia hay entre un Simple Factory y un creador concreto de un Factory Method? 1) Con el Factory Method podemos escoger los productos a crear en tiempo de ejecucin, Mientras que con el idiom si quisiramos aadir nuevos productos tendramos que aadir cdigo. No es correcto. En los dos se elige el objeto a crear en tiempo de ejecucin (dentro del cdigo del create). La diferencia primordial es que en factory method el creador concreto hereda de la clase padre el cdigo donde se va a utilizar ese create, mientras que en simple factory esto no est definido y puede ser cualquier objeto el que haga uso de la simple factory para pedirle objetos. Adems, podemos aadir varias simple factories para todos los subconjuntos de objetos que queramos crear, igual que en factory method. Cuestin 10: Deben ser los mtodos factora siempre abstractos? Y protegidos?

1) No tiene porque, ya que el mtodo tambin podra dar una implementacin por defecto y luego completarla en las subclases concretas. Correcto 2) No siempre tienen que ser abstractos, se les puede dar una implementacin por defecto y que las subclases los redefinan. Protegidos si deben de serlo para que solo sean accesibles por las subclases que los pueden redefinir, es decir las fabricas concretas. Correcto a medias. Deben ser protegidos para que slo se usen desde el mtodo de la clase padre que hace la llamada al create. Cuestin 11: Es obligatorio que el Factory Method o el create del Simple Factory tomen un parmetro para decidir que tipo de objeto crear? No pues otra opcin es que decidan por ellos mismos que objetos devolver.

Boletn 3.3.3: Strategy y Adapter

Cuestiones generales Cuestin 1: Cul es el principal objetivo del patrn Strategy? Y del Adapter? Strategy: Estructurar una familia de algoritmos de modo que sus clientes puedan intercambiarlos en tiempo de ejecucin Adapter: Convertir la interfaz de una clase en otra interfaz esperada por los clientes. Permite que clases con interfaces incompatibles puedan comunicarse

Cuestin 2: Qu situaciones pueden motivar la utilizacin de un Adapter? Que la clase cliente o la que tenemos que adaptar no puedan ser modificadas, o que sea mas costosa la modificacin de stas que crear un adaptador. Cuestin 3: Qu ventajas se consiguen con el patrn Adapter? Que una clase con interfaz incompatible pueda ser usada sin necesidad de modificar el cdigo existente. Como ventaja opcional conseguimos desacoplar el cliente y la clase adaptada. Cuestin 4: Qu ventajas se consiguen con el patrn Strategy? Aislar un punto de variacin que consiste en distintas implementaciones del mismo algoritmo, es decir, desacoplamos los clientes de los algoritmos de la implementacin concreta. Centralizamos su descripcin por lo que mejoramos su mantenibilidad y entendimiento. Adems, permitimos que se puedan reutilizar los algoritmos. Por ltimo, si Se mejora la cohesin del las clases que usan los algoritmos en aquellos casos en los que el diseo alternativo sea incluir los algoritmos como mtodos de las clases cliente. Cuestin 5: Qu relacin existe entre el patrn Template Method y el patrn Strategy? Describa sus relaciones y haga una tabla con ventajas e inconvenientes de cada patrn. 1) Los dos patrones son de tipo comportamiento, ambos permiten cambiar el cdigo. Mientras que el mtodo plantilla nos permite cambiar parte del cdigo por herencia, tiempo de compilacin. Tambin nos permite factorizar el comportamiento comn de un algoritmo y as evita que tengamos que duplicar cdigo, dejando que las extensiones se encarguen las subclases. Correcto

El estrategia nos permite cambiar todo el cdigo por composicin, en tiempo de ejecucin sin embargo tenemos que duplicar cdigo, es posible que obliguemos a una subclase implementar algo que no debe y adems no puedo reutilizar. La duplicacin de cdigo en el cliente no ocurrir siempre, pues depende de que incluyamos dentro del algoritmo de la estrategia y que no. Si aplicamos estrategia a algoritmos que son totalmente distintos pero que solucionan el mismo problema, no habr repeticin de cdigo. Con respecto a la reutilizacin, en estrategia se facilita la reutilizacin de los algoritmos, cosa que en template method no es posible puesto que obliga a que estos sean protected. La tabla resumiendo todo quedara como sigue: Patrn Ventajas Inconvenientes Template 1. Es adecuado para 2. Es poco flexible a los cambios en Method implementar frameworks tiempo de ejecucin por usar pues obliga a definir el herencia contexto (como/cuando) 3. No permite la reutilizacin de los donde se usan las distintas algoritmos (pasos en este caso) por versiones en el mtodo definirlos como mtodos gancho plantilla protected Strategy 4. Es ms flexible a los 6. No es adecuado para implementar cambios en tiempo de frameworks pues no indica el ejecucin gracias a la contexto (cuando/donde) donde se utilizacin de delegacin usan los algoritmos 5. Permite que cualquier objeto reutilice los algoritmos Cuestin 6: Qu diferencias existen entre el patrn Faade y el patrn Adapter? 1) El patrn Faade se utiliza para minimizar las dependencias, reducir la complejidad, es como un punto de entrada para los clientes. Con esto se consigue aislar al cliente de la complejidad del sistema, minimizando el acoplamiento y haciendo que cualquier cambio sea transparente a el. El patrn Adapter su funcin es que un cliente que usa un objeto de una interfaz pueda usar un objeto con una interfaz diferente sin tener que cambiar el cdigo de ninguno de los dos. Correcto. Matizar que fachada no desacopla completamente, pues fachada se usa para un caso de uso determinado y no para todos los usos. Cuestiones especficas Cuestin 7: Cuntas clases puede adaptar un Adaptador? Una o varias Si es posible que adapte a varias clases, entonces qu lo diferencia de Faade?

El objetivo de Faade es simplificar, mientras que Adapter trata de cambiar la interfaz de una clase para que pueda ser utilizada por el cdigo existente (que ha sido desarrollado para usar una interfaz distinta) Cuestin 8: Cmo puede conseguir que el comportamiento de una clase cambie en tiempo de ejecucin usando el patrn Strategy? Basta con aadir un mtodo setStrategy a la clase que usa las estrategias o aadir en esta clase el cdigo necesario para decidir que estrategia usar en cada momento

Boletn 3.3.4: Decorator

Cuestiones generales Cuestin 1: Cul es el principal objetivo del patrn Decorator? 1) El cumplir el principio abierto/cerrado, es decir que una clase se pueda extender sin que se vea afectada por las modificaciones. Poder modificar algo sin tener que aadir, cambiar cdigo. Aclarar que quin no debe verse afectado por las modificaciones es el cliente de esas clases. Con la aclaracin hecha es correcto, pero este no es el objetivo ms importante. El objetivo principal es: extender objetos de manera dinmica sin usar la herencia. Cuestin 2: Qu situaciones pueden motivar la utilizacin de un Decorator? 1) Cuando debido a la herencia se puede llegar a una explosin de clases, es decir muchos tipos de clases diferentes que no son ms que combinaciones de unas clases bsicas con unas clases que aaden algo nuevo y adems existen puntos de variacin. Adems deberamos aadir aquellas situaciones donde en tiempo de compilacin no se conocen las extensiones que necesitar un objeto. Cuestin 3: Qu alternativas hay a la utilizacin de un Decorator? 1) Un Decorador consiste en la delegacin, y la otra alternativa es mediante herencia. Correcto. Cuestin 4: Cundo es aconsejable no usar el patrn Decorator y usar la otra opcin? 1) Supongo que ser lo contrario a cuando usar el patrn, cuando me da igual fijar las cosas en tiempo de compilacin. Y adems no tienes explosin de herencia. Cuestin 5: Qu diferencias y similitudes observa entre el patrn Decorador y el patrn Strategy? 1) Similitudes que fijan en tiempo de ejecucin, pero no se me ocurre nada mas. Yo dira lo mismo de otro modo: Ambos pueden cambiar el comportamiento del objeto en tiempo de ejecucin. An as hay que tener claro que decorador aade/extiende el objeto, mientras que strategy mantiene el objeto con las mismas responsabilidades solo que modifica la forma en la que se llevan a cabo.

Cuestiones especficas Cuestin 6: Es posible decorar un objeto varias veces e incluso decorar otro decorador Que clases/relaciones permiten esto? 1) Las clases abstractas y las relaciones de herencia. Correcto. Es posible y esto es posible gracias a que tanto los decoradores como los objetos a decorar heredan/implementan la misma interfaz (interfaz, clase abstracta, clase). Cuestin 7: Todos los decoradores y objetos a decorar heredan/implementan la misma interfaz. Cmo se decide en una la implementacin JAVA si sta ser una clase abstracta o una interfaz? 1) Si podemos factorizar comportamiento comn de las subclases en la superclase utilizaremos una clase abstracta, para evitar as la duplicacin de cdigo, en cambio si no podemos factorizar comportamiento comn usaremos una interfaz. Correcto. Es importante que notis que al hablar de interfaz en diseo nos referimos al conjunto de responsabilidades que ofrece un objeto y no al concepto de interface JAVA. Cuestin 8: Como puede conseguir cambiar el objeto al que se decora en tiempo de ejecucin? Y el decorador? 1) Para cambiar el objeto al que se decora en tiempo de ejecucin, habra que sustituir dicho objeto con una llamada al constructor del decorador concreto. Es decir c = new decoradorconcreto( c ); Para cambiar el decorador supongo que hara falta un decorador para el decorador. Ms o menos bien. Otra opcin para cambiar el objeto que se decora es aadir un mtodo setDecorado en los decoradores. Para cambiar los decoradores basta con crear el nuevo decorador y fijarle el objeto a decorar: bien con el constructor o con el mtodo setDecorado.