Patrones de diseño: Test 1

1. ¿Cuál es el objetivo del patrón Strategy?

a) Definir el esqueleto de un algoritmo dejando la implementación de algunos de los
pasos del esqueleto a las subclases.
b) Permite la coexistencia “pacífica” de una “familia de algoritmos” (conjunto de
algoritmos que realizan variantes de una tarea) encapsulando cada algoritmo como un
objeto para desacoplarlo (sacarlo fuera) así de los clientes.
c) Permite añadir dinámicamente nuevas responsabilidades/nuevo comportamiento a
un objeto, proporcionando una alternativa a la definición de subclases.

2. El diseñador de una aventura gráfica tiene distintos tipos de monstruos (duendes,

fantasmas y demonios). Desea que en el escenario haya unos lugares especiales en los
que se vayan generando estos monstruos y desea que a lo largo del tiempo el tipo de
monstruo que se cree vaya cambiando. Así, quiere que durante los primeros 2 minutos
de juego se generen fantasmas, durante los siguientes minutos se generen duendes y
que, cuando el héroe haya llegado a una determinada habitación sólo se generen
demonios.

Si queremos eliminar el código spaghetti (if...then...else...if...) que decide qué tipo de

monstruo generar en cada momento sin crear nuevas clases tenemos que aplicar el
patrón...
a) Singleton
b) Prototype
c) Factory Method

3. ¿Cuál es el objetivo del patrón State?

a) Permite la coexistencia “pacífica” de una “familia de algoritmos” (conjunto de
algoritmos que realizan variantes de una tarea) encapsulando cada algoritmo como un
objeto para desacoplarlo (sacarlo fuera) así de los clientes.
a) Definir el esqueleto de un algoritmo dejando la implementación de algunos de los
pasos del esqueleto a las subclases.
c) Permite que un objeto se comporte de distinta forma dependiendo de un estado,
como si cambiase la clase a la que pertenece.
4. La aventura gráfica anterior se maneja exclusivamente usando el teclado. Las teclas
È y Ç sirven para cambiar de opción en el menú de entrada del juego y para hacer
que el personaje se mueva hacia atrás y hacia adelante cuando estamos jugando. El
método de la clase Juego responsable de manejar los eventos de teclado es similar a
éste:
protected void procesarEntradaUsuario() {
switch(TECLA_PULSADA) {
case FLECHA_ARRIBA: if (MENU);
// Cambiar opción del menú
else if (JUGANDO)
// Mover personaje hacia adelante
break;
case FLECHA_ABAJO: if (MENU);
// Cambiar opción del menú
else if (JUGANDO)
// Mover personaje hacia atrás
...
}
}
Se ha añadido una nueva funcionalidad: el usuario puede entrar en una nueva pantalla
en la que consulta el inventario del personaje. Las teclas È y Ç le servirán para
moverse por los distintos objetos que guarde el personaje en el inventario. Podemos
seguir complicando la lógica del método procesarEntradaUsuario o podemos
refactorizar este código y aplicar el patrón...
a) Decorator
b) Composite
c) State

5. En el patrón Decorator, ¿Cuál es el papel de Component?

a) Define la interfaz de los objetos a los que se les pueden añadir responsabilidades
dinámicamente
b) Define el interfaz de la clase que decora gráficamente a otros objetos.
c) Almacena una referencia a un objeto y define una interfaz que se ajusta a la del
mismo
6. Casi todos los elementos gráficos de Java heredan de la clase JComponent. Cuando
se dibuja un JComponent se puede dibujar un borde alrededor del componente,
invocando a su método paintBorder. La manera “equivocada” de implementar este
método sería la siguiente:
protected void paintBorder(Graphics g) {
switch(getBorderType()) {
case LINE_BORDER: paintLineBorder(g);
break;
case ETCHED_BORDER: paintEtchedBorder(g);
break;
case TITLED_BORDER: paintTitledBorder(g);
break;
...
}
}
En cambio, la clase JComponent delega en la clase Border para pintar dicho borde.
protected void paintBorder(Graphics g) {
Border border = getBorder();

if (border != null) {
border.paintBorder(this, g, 0, 0, getWidth(), getHeight());
}
}
Hay distintas implementaciones de la clase Border. Incluso, podemos crear nuestros
propios tipos de bordes. Los distintos tipos de bordes se pueden ver en la siguiente
figura:

Como se puede ver, esto es un ejemplo del patrón:

a) Decorator
b) Strategy
c) Observer
7. Una de las consecuencias del patrón de creación Prototype es:
a) Nos da un acceso controlado a la única instancia que se puede crear del prototipo.
b) Dificulta la definición de nuevos productos
c) Permite cambiar el tipo de producto en tiempo de ejecución.

8. En el patrón Factory Method, la clase que hace el papel de Creator declara el

método FactoryMethod(), el cual:

a) Devuelve un objeto de tipo Product

b) Devuelve un objeto de tipo ConcreteCreator
c) Devuelve un objeto de tipo ConcreteProduct

9. La clase FilterInputStream es la responsable de añadir funcionalidades de filtrado y

procesado de la información que llega por un InputStream. A continuación, podemos
ver un extracto del diagrama de clases.

Este diseño ilustra el patrón de diseño...

a) Decorator
b) Adapter
c) Observer
10. Las características de cada uno de los monstruos que aparecen en una aventura
gráfica se guardan en un archivo de texto. Para cada monstruo hay un archivo de texto
diferente. Debido a las distintas versiones del juego cada monstruo (Duende, Fantasma
y Demonio) se guarda en un formato totalmente distinto. Para paliar este problema se
ha creado un cargador de personajes para cada uno de los monstruos existentes. El
diseño de clases de estos cargadores queda como sigue:

El método inicializar(String nombreFichero) es el encargado de establecer cuál es el

fichero que se pretende cargar. El método cargar() crea y devuelve un objeto de la
subclase de Monstruo correspondiente. Este método interpreta el rol…
a) Clone() del patrón Prototype
b) Request() del patrón State
c) FactoryMethod() del patrón Factory Method