Introducción

En esta práctica ampliaremos la práctica 2 con nuevos tipos de cazas derivados de la clase Fighter, y con la creación y gestión de excepciones para tratar los diferentes errores que puedan producirse. Las clases Coordinate y RandomNumber no cambian con respecto a la práctica 2, y las clases Ship y Board tienen cambios relacionados en su mayor parte con las excepciones. La clase Fighter se convierte en una clase abstracta de la que heredan 6 nuevas clases (3 para cazas rebeldes, y 3 para cazas imperiales); además, se añade una clase factoría FighterFactory para crear cazas. Por otro lado, se crearán 6 excepciones que es necesario usar y tratar en las clases Fighter, Ship y Board.

Diagrama de clases

El siguiente diagrama de clases UML representa las clases de nuestro modelo. Solamente se muestra la clase FighterFactory, la clase Fighter y sus clases derivadas, las clases Coordinate, RandomNumber, Ship y Board no aparecen porque su interfaz no cambia. En la clase Fighter solamente se muestran los cambios (los métodos abstractos aparecen en cursiva, y cambia la visibilidad de los constructores y desaparece el argumento type del constructor):

Las excepciones derivan todas de la clase estándar java.lang.Exception (o Exception), el diagrama de las clases de excepciones es:

La nueva clase FighterFactory pertenece al paquete model, y las clases derivadas de Fighter pertenecen al paquete model.fighters; finalmente, las excepciones pertenecen al paquete model.exceptions.

Hoja de ruta

Las dos partes de la práctica (herencia y excepciones) son bastante independientes, por lo que aunque en esta hoja de ruta se aconseja empezar por la herencia, también sería posible empezar por las excepciones. El orden aconsejado para ir construyendo tu práctica es:

• Añade la clase factoría FighterFactory, y utiliza el método createFighter para crear cazas (en vez de new Fighter(...)
• Convierte la clase Fighter en abstracta (añadiendo abstract entre public y class), modifica los argumentos y la visibilidad de los constructores (ahora son protected) y declara como abstractos los métodos que aparecen en el diagrama: copy y getSymbol
• Crea el paquete model.fighters e implementa las clases derivadas (son todas muy similiares, puedes copiar/pegar desde la ventana del proyecto)
• Crea el paquete model.exceptions e implementa las excepciones (también son todas muy parecidas, puedes copiar/pegar)
• Finalmente, modifica las clases Fighter, Ship y Board para que lancen y capturen las excepciones

Recuerda, ve diseñando pruebas unitarias según vayas terminando cada clase, y utilízalas para depurar tu código antes de pasar a la siguiente clase.

FighterFactory

Se trata de una clase factoría de la que nunca se crean objetos y sólo tiene un método estático para crear cazas. Debes usar este método para crear cazas porque el constructor de Fighter será protected y sólo lo utilizarán sus subclases.

Fighter y sus subclases

Esta clase se convierte en abstracta, por lo que en esta práctica no va a ser posible crear objetos Fighter, aunque sí seguiremos manejando variables de tipo Fighter, que harán referencia a un objeto de una de sus subclases. Como se puede observar en el diagrama UML, los dos constructores de Fighter pasan a ser protected, por lo que solamente serán usados desde sus subclases (con super(…)).

El atributo type de la clase Fighter desaparece (debes eliminar la línea private String type y las referencias al atributo en los constructores), y el método getType debe obtener el tipo del caza del nombre de la clase:

    public String getType() {
        return getClass().getSimpleName();
    }

En los métodos que necesiten el atributo type debes usar el método getType en su lugar.

Para crear un nuevo caza se utilizará el método createFighter de la clase FighterFactory (que creará el caza usando el constructor correspondiente de la subclase indicada en el argumento type), y para obtener una copia de un caza se debe usar el método copy, que tendrá que implementarse en todas las subclases de forma que invoque al constructor de copia de la subclase, que a su vez invocará al constructor de copia de Fighter (que es la única forma de construir una copia). De esta manera, cuando queremos copiar una variable de tipo Fighter invocamos al método copy (que se transformará automáticamente en una llamada al método copy de la subclase de Fighter a la que pertenezca el objeto contenido en la variable).

Los métodos abstractos se declaran en Fighter de esta manera (la documentación de cada método debe estar en Fighter, en las subclases no se debe poner):

        public abstract Fighter copy();

        public abstract char getSymbol();

En cada una de las subclases se debe implementar todos los métodos abstractos, por ejemplo en la clase AWing el método getSymbol se implementaría así:

        @Override
        public char getSymbol() {
                return 'A';
        }

Por otro lado, como se puede ver en el diagrama UML, muchos cazas tienen su propio método getDamage porque cambia la forma de calcular el daño en función de qué tipo de caza sea el caza enemigo. Solamente en las clases TIEFighter y XWing no se implementa este método porque no hay refinamiento (no cambia el comportamiento con respecto al método de la superclase Fighter), en cuyo caso se usará el método de la superclase.

NOTA: la directiva @Override se debe colocar antes de los métodos que sobreescriben un método de la superclase. No es obligatoria pero sí muy aconsejable, sirve para indicar al compilador que ese método sobreescribe un método de una clase superior, de forma que si hubiera algún error en la signatura del método derivado, el compilador nos daría un error. Por ejemplo, si en el método equals el tipo del argumento no fuera Object, al poner @Override el compilador daría error; si no hubiéramos puesto @Override en equals el compilador no daría error y llamaría al método equals de la clase superior (en ese caso, Object, aunque no tiene relación con que el argumento sea Object). En el caso de los métodos abstractos, el compilador detectaría otro error (que falta por implementar un método abstracto), pero aún así es aconsejable usar @Override siempre que se sobreescribe un método (especialmente en el caso de equals, hashCode y toString).

Los métodos de las subclases de Fighter tienen que hacer lo siguiente:

Lanzamiento de excepciones

Cuando un método detecta una situación de error en su código que no puede tratar o que debe ser tratada en alguno de los métodos que lo han invocado, debe lanzar la excepción de esta manera:

   if (situacion de error provocada por 'a')
      throw new ExampleException(a);

Cuando un método lanza alguna excepción, debe declararlo añadiendo una cláusula throws en su declaración (y una @throws en la documentacion de Javadoc):

   public void metodoQueHaceAlgo(int a,Objeto b) throws ExampleException {
    ...
      throw new ExampleException(a);
    ...

El entorno Eclipse ayuda en esta tarea (como en otras muchas) y sugiere añadir la cláusula throws justo después de completar la línea throw new ..., y también añade la cláusula @throws a la documentación (que debe completarse indicando en qué situación se lanza la excepción, p.ej. algo como @throws ExampleException cuando el argumento ‘a’ es negativo)

Captura y propagación de excepciones

Cuando un método Y invoca a otro método Z que lanza excepciones, el método Y tiene que elegir entre dos opciones:

1. Propagar la excepción y que sea el método que lo ha invocado (p.ej. X o uno anterior en la secuencia de invocaciones) el que trate la excepción. Para esto simplemente se debe añadir la cláusula throws a la declaración (y la @throws en la documentación)

2. Capturar la excepción, envolviendo al método Z en un bloque try-catch

Cuando el entorno Eclipse detecta esta situación (que, hasta que se elija una opción, genera un error de compilación) sugiere todas las opciones posibles, que pueden ser bastantes cuando hay más métodos que lanzan excepciones en el método Y.

Excepciones utilizadas en esta práctica

En muchos casos, las excepciones se producen por errores de programación, por lo que al capturarlas se debe lanzar una excepción especial:

  throw new RuntimeException();

Las excepciones Runtime no se declaran con throws, son un error de ejecución que no tiene tratamiento posible dentro de la lógica del programa porque son un error de programación.

Las excepciones en esta práctica deben capturarse en el programa principal salvo que se indique lo contrario. En posteriores prácticas es posible que se capturen en otras clases. Si un método (p.ej. launch) puede lanzar más de una excepción, debe lanzarlas en el orden en el que aparecen en este apartado.

El mensaje que hay que devolver en los métodos getMessage debes decidirlo tú, y debe incluir el valor que ha causado la excepción y la cadena ´ERROR:´ al principio, como por ejemplo:

    public String getMessage() {
        return "ERROR: invalid size "+size;
    }