Sesión 5

Modificadores de acceso. Miniproyecto.

1. Modificadores de acceso

Vamos a comenzar la última sesión del módulo con un pequeño ejercicio para comprobar los modificadores de acceso de Java.

Antes de nada, hagamos un pequeño resumen. En Java existen cuatro posibles niveles de acceso: private, por defecto (si no declaramos nada), protected, public. Estos cuatro niveles tienen la siguiente política de acceso:

• private: no se permite el acceso al elemento, ni siquiera para los objetos de alguna subclase. Sólo se puede acceder al elemento desde la misma clase. Si, por ejemplo, declaramos un método A de una superclase Super como private, ese método A no es heredado por las subclases de Super.
• defecto: es el nivel de acceso que tiene un elemento si no declaramos nada. Se puede acceder al elmento desde cualquier clase del mismo paquete. Si, por ejemplo, el campo A de la clase Clase1 que está en el paquete modulo1.sesion5 no tiene modificador de acceso (tiene un acceso por defecto), cualquier clase de este paquete va a poder acceder a su valor.
• protected: puede ser que una subclase no esté en el mismo paquete que la superclase. Si un elemento tiene el modificador protected, se puede acceder a él desde el mismo paquete y desde cualquier subclase, aunque la subclase no esté en el mismo paquete.
• public: un elemento public es accesible desde cualquier otra clase sin ninguna restricción.

1. Vamos a hacer un pequeño ejercicio para probar estos niveles de acceso. Supongamos la siguiente clase en el paquete modulo1.sesion5

   package modulo1.sesion5;
   public class Acceso {
       public int valorPublico;
       int valorDefecto;
       protected int valorProtected;
       private int valorPrivate;
   }

   y ahora supongamos las dos siguientes clases que van a comprobar el acceso a los campos de Acceso:

   package modulo1.sesion5;
   public class TestAcceso{
       public void testeador() {
           int i;
           
           Acceso acceso = new Acceso();
           i = acceso.valorPrivado;
           i = acceso.valorDefecto;
           i = acceso.valorProtected;
           i = acceso.valorPublico;
       }
   }

   package modulo1.sesion5;
   public class TestAccesoSubclase extends Acceso{
       public void testeador() {
           int i;
          
           i = this.valorPrivado;
           i = this.valorDefecto;
           i = this.valorProtected;
           i = this.valorPublico;
       }
   }
   

   La primera clase es una clase normal que está en el mismo paquete y la segunda es una subclase de Acceso. Contesta a las siguientes preguntas en el fichero respuestas.txt:

   • ¿En qué campos de la clase TestAcceso hay un error?
   • ¿En qué campos de la clase TestAccesoSubclase hay un error?
2. Copia ahora ambas clases de prueba en el paquete modulo1.sesion4, modificando la instrucción package y añadiendo el import de la clase modulo1.sesion5.Acceso:

   package modulo1.sesion4;
   import modulo1.sesion5.Acceso;

   ¿Qué ha cambiado ahora? ¿Qué componentes son accesibles?

2. Miniproyecto

En el fichero de plantillas de esta sesión se encuentran la siguientes clases que implementan un sencillo juego de un laberinto: Posicion, Laberinto Jugador, EstadoJuego, Vista, Controlador, JuegoLaberinto y JuegoLauncher.

Vamos primero a explicar brevemente el funcionamiento del juego y después comentaremos el ejercicio a realizar.

Funcionamiento del juego

El juego define un laberinto (siempre el mismo) en el que se mueve el jugador. La posición inicial del jugador es aleatoria. El jugador se mueve introduciendo un comando de texto. El laberinto y el jugador aparecen representado en modo texto y se muestra por la salida estándar cada vez que el jugador ha introducido un comando:

# #############
#    *  #     #
# ### # # ### #
#   # #   ### #
### ########  #
#   #   ####  #
# ### ###### ##
# #    ##### ##
#   ##     # ##
############ ##

INTRODUCE MOVIMIENTO (A,B,D,I,S)>

Diseño e Implementación

El juego se ha diseñado siguiendo la estrategia (o el patrón, como se suele decir) Modelo-Vista-Controlador. La idea de esta estrategia es independizar el funcionamiento del programa de su presentación al usuario. De esta forma, es más sencillo modificar la interfaz de usuario (la forma de obtener los datos del usuario y de presentar los resultados) sin afectar al funcionamiento del programa.

En nuestro caso, tenemos la clase Vista que se encarga de mostrar el laberinto y de obtener la instrucción del usuario. Tenemos también la clase Controlador que se encarga de realizar un paso de ejecución del juego. Y, por último, tenemos las clases Jugador, Laberinto y EstadoJuego que mantienen los distintos elementos del juego.

Si, por ejemplo, quisiéramos adaptar el juego a un entorno gráfico, sólo tendríamos que modificar la clase Vista y esto no afectaría al funcionamiento interno del juego.

Vamos ya a plantear los ejercicios:

1. Compila todas las clases en el paquete modulo1.sesion5 y prueba que funciona la aplicación.
2. Modifica la aplicación para incluir las siguientes características:
• Incorporar un jugador enemigo (lo llamaremos robot) que se mueve aleatoriamente por el laberinto.
• Si chocan en la misma celda el robot y el jugador, terminar el juego con un mensaje de error. Por ejemplo:"Fin de partida. Has chocado".
• Si el robot sale del laberinto, terminar el juego con un mensaje. Por ejemplo: "Fin de partida. Ha ganado el robot".

PARA ENTREGAR

Debes crear un ZIP llamado sesion5.zip con:

• El fichero de texto respuestas.txt con las cuestiones contestadas
• Los ficheros con las clases que has implementado y modificado.