¿es malo para almacenar diferentes clases hijas como clase padre en Java

Patrick Anderson:

¿Se considera mala práctica de los objetos de almacén como su clase padre y comparar object.getClass () con una clase de espera que se convierta a la subclase.

explicación: como parte de un juego en 2D con el movimiento Pieza de base Tengo varios tipos de "GameObject" objetos como "Portal", "Jugador", "APN", "Pecho", etc Cada uno se almacena en una matriz de 2 dimensiones que componen cada Nivel, que también actúa como una actualización y una cola de renderizado y el GameObject encarna la información requerida por el nivel. Si puedo almacenar todos los objetos como el GameObject tipo padre luego las echó en su clase real, por ejemplo (en la clase de jugador):

private void checkPosition(x, y) {
    GameObject obj = Level.getObject(x,y);
    if(obj instanceof NPC) {
       NPC npc = (NPC)obj;
       //interact with npc
    } else if(obj instanceof Chest) {
       //handle chest
    }
}

¿Esto generalmente será más difícil de leer? ¿Qué problemas soy yo propensos a tener hacer las cosas de esta manera? lo que sería un método mejor si cualquiera siempre que cada objeto utiliza la matriz de interactuar unos con otros y es probable que tendrá otros tipos de "GameObjects" en el futuro, cada uno con funcionalidad fundamentalmente diferente.

Lo siento si esto es prolijo ya que no estoy muy seguro de cómo explicar esta pregunta.

edit: Debo aclarar código similar puede ser ejecutado desde otras clases sub de GameObject, no sólo del jugador (es decir, NPC o una después de clases) y el énfasis está en ser capaz de cambiar la interacción entre cada clase sub sin cambiar la clase de Nivel almacenar cada de una vez de que es potencialmente almacenado se crea / cambiado el tipo de clase. gracias a los que recomendó instanceofHe actualizado la cuestión de centrarse en otras partes, pero es probable que se utilizaba a partir de ahora. Gracias por la respuesta.

Conclusión: He decidido ir a por una variante de la respuesta de daniu donde cada uno tiene su propia GameObject subclase AI que se extiende un talón / adaptador de la interfaz mencionada. Por lo tanto no tengo para poner en práctica las reacciones de clase alguna, puedo dar diferentes comportamientos para el mismo tipo de objeto y el manejo de la interacción debería tener este aspecto:

getObject(x,y).getAI().react(obj);

plato:

Este es un caso de uso para el patrón de visitante.

Añadir una interfaz (por todo lo que pueden moverse a través del nivel)

interface LevelCrawler {
   void accept(Chest chest);
   void accept(NPC npc);
}

y para su GameObject

interface GameObject { // or abstract class
    // added method
    void accept(LevelCrawler lc);  // abstract if class
}

El LevelCrawlerse pueden implementar, por ejemplo, la Playerclase (o NPC, etc, ya que describes en tu edición).

class Player implements LevelCrawler {
   public void accept(Chest chest) { ... }
   public void accept(NPC npc) { ... }
}

que contiene el código de los if () {...}bloques.

Entonces, por ejemplo, usted tiene

class Chest implements GameObject {  // I think it's a class, so probably "extends"
    void accept(LevelCrawler p) { p.handle(this); } // to call Player#handle(Chest)
}

y el código tiene

GameObject o = Level.getObject(x, y);
o.accept(player); // or NPC or whatever is moving right now

Mira, funciona .

La ventaja de esto es que cuando se crea una nueva GameObjectclase, puede agregar fácilmente el nuevo comportamiento a los existentes LevelCrawlerclases y dejar el checkPositioncódigo sin cambios.

Editado versión con ambos Playery NPCse mueve a través de la mazmorra.