Herencia en Core Java

Question

Para mi tarea, se nos ha encomendado la tarea de "declarar una matriz de cuatro" empleados universitarios regulares ", tres profesores y siete estudiantes. Pedir al usuario que especifique qué tipo de datos se ingresarán (C, F, S) o la opción para salir (Q). Mientras el usuario continúa, acepte la entrada de datos para la persona adecuada. Muestre un mensaje de error si el usuario ingresa más que el número especificado para cada tipo de persona. un informe en la pantalla que enumere cada grupo de personas bajo el encabezado apropiado. Si el usuario no ha ingresado datos para uno o más tipos de Persona durante una sesión, muestre un mensaje apropiado debajo del encabezado apropiado ".

Class   | Extends   | Variables 
-------------------------------------------------------- 
    Person   | None   | firstName, lastName, streetAddress, zipCode, phone 
    CollegeEmployee | Person   | ssn, salary,deptName 
    Faculty   | CollegeEmployee | tenure(boolean) 
    Student   | person   | GPA,major 

Después de leer el Tutorials sobre sucesiones y arrastre un montón de discusiones de herencia, creo que lo tengo a la derecha en el papel, pero preferiría alguna entrada antes de que consiga los codos de profundidad en el código que no funciona. :)

estoy definiendo

Person[x] = new Student(); 

(o Faculty o CollegeEmployee).

La clase Person tiene todos los campos de entrada para un Person, y las subclases tienen sólo los datos adicionales (por ejemplo, major en el caso de Student).

Cuando creo el new Student(); los campos de entrada tanto en el People clases y Student estarán disponibles para mí porque Student extiende People y las variables adicionales definidas en Student se agregan para la definición de Person para esa instancia.

Cuando llega el momento de extraer datos de la matriz, Java lo ve como una matriz de Person, así que tengo que agregar lógica

if Person[x] instanceof Student (or `Faculty` or `CollegeEmployee`) 

para ejecutar las acciones apropiadas para el tipo de Person. Mi sensación es que el instanceof está actuando para anular (en este caso para anexar) lo que Java sabe sobre la clase Person en el lado de salida.

¿Me falta algún entendimiento crítico de esto?

Answer 1

No solo hay herencia, sino polimorfismo: simplemente ingrese el código necesario para ingresar y validar los datos del objeto en el método de objeto (ej .: inputMyData() reemplazando el método base en persona, posiblemente llamando al método de superclase) - de esta manera usted puede evitar instanceof y casting.

Answer 2

En general, se debe evitar instanceof. Lo simple en este caso parece ser hacer tres arreglos: un CollegeEmployee[], un Faculty[] y un Student[], en lugar de agruparlos todos en uno Person[] y clasificarlos más adelante.

Respuesta original a continuación:

Si estoy entendiendo lo que estás tratando de hacer correctamente, instanceof no es necesario.

Si se escribe algo así como

Person bob = new Student(); 
bob.someAction(); 

donde someAction es un método definido para Person y anulado por Student, entonces Java llamar a la versión Student, incluso si el método se llama en una variable Person.El despacho dinámico garantiza que las llamadas a métodos siempre se resuelvan en la versión del método implementado por el tipo de objeto real, no en el tipo de variable.

Tenga en cuenta que esto solo funciona si someAction se define como un método abstracto o concreto por Person. Si se introduce por primera vez en Student, entonces debe hacer un lanzamiento explícito.

Answer 3

En primer lugar, la dirección debe ser más bien un objeto separado.

En segundo lugar, Student no puede ser un descendiente directo (en) de Person, como estudiante es un/trabajo de papel cívico-estado (que es incluso difícil de definir) y persona es un synonyme para el ser humano, que, por otra parte es una especie. En otras palabras, no puede decir que el estudiante es un caso especial de persona (inheritance), pero puede decir que esa persona tiene un (composition) estado cívico de estudiante.

Si echas un vistazo a las propiedades de tus clases, también notarás que no representan lo mismo. Cada objeto debe enfocarse en una cosa (single responsibility principle), mientras que el objeto Person define el nombre y el apellido, la edad, etc. (propiedades relacionadas con la persona) y CollegeEmployee define el salario y el nombre del departamento (propiedades relacionadas con el trabajo). Propiedades totalmente no relacionadas

En pocas palabras, una persona es un objeto realmente complejo y es un ejemplo horrible para una persona que intenta comprender los principios del diseño OO.