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 clases-
algoritmos, 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.