Universidad Carlos III de Madrid

Grado en Ingeniería Telemática/Grado en Ingeniería de Sistemas de Comunicaciones

Enero-Mayo 2014

Orientación a Objetos y Herencia

Tabla de contenidos

1. Sesión 4 (laboratorio): Orientación a Objetos y Herencia (II)
1.1. Jerarquías de clases y polimorfismo

Lab Section1. Sesión 4 (laboratorio): Orientación a Objetos y Herencia (II)

Exercise Section1.1. Jerarquías de clases y polimorfismo

Los encargados de la piscina de la UC3M le han pedido que programe una aplicación Windows para gestionar a los usuarios de la piscina.

La aplicación tendrá una sencilla base de datos con todos los usuarios de la piscina y será capaz de mostrar una lista completa del contenido de la base de datos: todos los usuarios con todos sus detalles conocidos.

Existen 5 tipos de usuarios de la piscina:

  1. Outsider: Externos, son personas que no tienen relación directa con la universidad, por ejemplo, vecinos de Leganés. De ellos solo se conoce su DNI.

  2. Staff: Personal de administración y servicios, son trabajadores de la universidad que no imparten docencia. Además de su DNI, se conoce su sueldo.

  3. Professor: Profesores, también son trabajadores de la universidad, pero se encargan de la docencia. Además de su DNI, se conoce el departamento al que pertenecen y su sueldo.

  4. Student: Alumnos, además de su DNI, se conoce su NIA.

  5. Intern: Becarios, son alumnos que han sido contratados temporalmente por la universidad. Además de sus datos como alumno, se conoce también su sueldo.

Apartado 1. Jerarquía de clases

¿Cúal de las siguientes figuras le parece más apropiada para describir la jerarquía de clases de la aplicación? Valore cada una de ellas según distintos criterios que se le ocurran y discútalos con un compañero. Dedíquele unos 15 minutos.

Apartado 2. Polimorfismo

Implemente la aplicación utilizando el modelo de la figura D. Programe todas las clases. Además de la declaración de sus atributos y de un constructor, cada clase debe proporcionar un método String toString() que genere una representación textual de la información conocida del usuario según el formato que se muestra más abajo.

En una clase de prueba aparte, que contenga únicamente un método main, vaya creando distintos objetos de usuarios (los listados más abajo) para probar la aplicación. Incluya estos objetos en una variable que sea capaz de almacenar varios objetos de la clase Person (cualquier contenedor Java servirá, por ejemplo un objeto de la clase ArrayList<Person>...) Luego recorra todos los elementos del contenedor y escriba los detalles de cada usuario en la salida estándar.

El comportamiento esperado de su aplicación es el siguiente (el orden en que imprima los usuarios es irrelevante): 

C:\Users\Alberto>java DataBase
DNI: 01100000-A
DNI: 00220000-B
DNI: 00030000-C, salary: 2000
DNI: 04040000-D, salary: 1500
DNI: 50500000-E, salary: 1000, department: mathematics
DNI: 66600000-F, salary: 2000, department: telematics
DNI: 77000000-G, NIA: 777777
DNI: 88080000-H, NIA: 888888
DNI: 90990000-I, NIA: 999999, salary: 400
DNI: 10100000-J, NIA: 101010, salary: 800

Apartado 3.

  1. Discuta con su compañero cómo es posible que a pesar de utlizar una referencia a Person a la hora de imprimir cada usuario, se esté ejecutando el método toString() de su clase original correspondiente (Staff, Professor, Student...)

  2. Discuta con su compañero por qué es necesario declarar el método String toString() como público en Person y sus subclases, en lugar de usar otros modificadores de acceso que podrían ser más adecuados para proteger el acceso a este método (como package-private, por ejemplo).

Apartado 4. Cambios de última hora

A falta de unas pocas horas para la fecha de entrega de su aplicación, la UC3M le pide 2 modificaciones extra:

  • Añada un nuevo tipo de usuario Tenured (Profesor funcionario), que sea como un profesor, pero con un sueldo fijo de 2500 Euros. Esto quiere decir que el constructor de esta clase no debe recibir el sueldo como argumento. Añada estos dos ejemplos de profesores funcionarios a la base de datos: 

    DNI: 11110000-K, salary: 2500, department: geography
DNI: 12120000-L, salary: 2500, department: mathematics

  • Cuando se lanze la aplicación con el argumento de línea de comandos "-s" (del inglés short) en vez de listarse todos los detalles de los usuarios, se debe imprimir un listado resumido, únicamente con los datos disponibles desde la clase básica Person.

El comportamiento esperado por la nueva versión de la aplicación es el siguiente: 

; java DataBase
DNI: 01100000-A
DNI: 00220000-B
DNI: 00030000-C, salary: 2000
DNI: 04040000-D, salary: 1500
DNI: 50500000-E, salary: 1000, department: mathematics
DNI: 66600000-F, salary: 2000, department: telematics
DNI: 77000000-G, NIA: 777777
DNI: 88080000-H, NIA: 888888
DNI: 90990000-I, NIA: 999999, salary: 400
DNI: 10100000-J, NIA: 101010, salary: 800
DNI: 11110000-K, salary: 2500, department: geography
DNI: 12120000-L, salary: 2500, department: mathematics
; java DataBase -s
DNI: 01100000-A
DNI: 00220000-B
DNI: 00030000-C
DNI: 04040000-D
DNI: 50500000-E
DNI: 66600000-F
DNI: 77000000-G
DNI: 88080000-H
DNI: 90990000-I
DNI: 10100000-J
DNI: 11110000-K
DNI: 12120000-L

  1. Estime cuánto tiempo necesitará para implementar cada uno de estos cambios por separado, en horas o minutos.

  2. Implemente todos estos cambios en una nueva versión de la aplicación y compare el tiempo empleado con su estimación inicial.