È buona norma usare spesso instanceof?

Question

Lo scenario. Sto scrivendo il codice relativo al gioco. In quel gioco uno Player (è anche una classe) ha un elenco di Item. Esistono altri tipi di elementi che ereditano da Item, ad esempio ContainerItem, DurableItem o WeaponItem.

Ovviamente è molto conveniente per me avere solo List<Item>. Ma quando ottengo gli elementi dei giocatori, l'unico modo per me di distinguere tra che tipo di elemento è utilizzando la parola chiave instanceof. Sono sicuro di aver letto che relying su di esso è una cattiva pratica.

È corretto utilizzarlo in questo caso? O dovrei ripensare a tutta la mia struttura?

Answer 1

Diciamo che sto scrivendo un certo codice di inventario:

public void showInventory(List<Item> items) { 
    for (Item item : items) { 
     if (item instanceof ContainerItem) { 
      // container display logic here 
     } 
     else if (item instanceof WeaponItem) { 
      // weapon display logic here 
     } 
     // etc etc 
    } 
} 

che compilerà e funzionano bene. Ma manca un'idea chiave del design orientato agli oggetti: È possibile definire le classi genitore per fare cose utili generali e fare in modo che le classi figlie inseriscano dettagli specifici importanti.

approccio alternativo sopra:

abstract class Item { 
    // insert methods that act exactly the same for all items here 

    // now define one that subclasses must fill in themselves 
    public abstract void show() 
} 
class ContainerItem extends Item { 
    @Override public void show() { 
     // container display logic here instead 
    } 
} 
class WeaponItem extends Item { 
    @Override public void show() { 
     // weapon display logic here instead 
    } 
} 

Ora abbiamo un posto per guardare, il metodo show(), in tutte le nostre classi figlie per la logica di visualizzazione dell'inventario. Come lo accediamo? Facile!

public void showInventory(List<Item> items) { 
    for (Item item : items) { 
     item.show(); 
    } 
} 

Stiamo mantenendo tutta la logica specifica per voce dentro specifiche sottoclassi Item. Ciò facilita la manutenzione e l'estensione del codice base. Riduce la deformazione cognitiva del ciclo lungo per ogni ciclo nel primo esempio di codice. Inoltre, è pronto per essere riutilizzato in luoghi che non hai ancora progettato, show().

Answer 2

Si dovrebbe ripensare la struttura, instanceof in codice non meta è quasi sempre un segno per un anti-pattern. Prova a definire il comportamento che tutti i Item hanno in comune (come avere un'immagine, una descrizione e qualcosa che accade quando si fa clic su di essi) nell'interfaccia Item, utilizzando la parola chiave abstract se appropriato e quindi utilizzare polymorphism per implementare le specifiche.

Answer 3

IMHO utilizzando instanceof è un odore di codice. In poche parole: rende il codice procedurale, non orientato agli oggetti. Il modo OO per farlo è utilizzare lo visitor pattern.

Il modello visitatore consente inoltre di creare facilmente decorator s e chain of responsibility su di esso, ottenendo così la separazione degli interessi, che si traduce in più brevi, più pulito e più facile da leggere e il codice di prova.

Inoltre, lo è davvero necessario conoscere la classe esatta? Non puoi approfittare del polimorfismo? Dopotutto lo Axe è un Weapon proprio come lo è Sword.

Answer 4

È consigliabile ripensare forse e provare a utilizzare il polimorfismo per implementare l'idea List<Item>.

Ecco alcuni riferimenti per il vostro problema che probabilmente può aiutare:

• Prefer polymorphism over instanceof and downcasting
• instanceof versus getClass in equals Methods (Interview with Josh Bloch)
• Polymorphism and Interfaces (vedere la sezione su quando utilizzare instanceof)

---

(Riferimenti da Is instanceof considered bad practice? If so, under what circumstances is instanceof still preferable?)

Answer 5

Va bene se è facile da capire.

Lo spostamento delle logiche di ramificazione da cui appartengono naturalmente a sottoclassi non è necessariamente una buona idea. Può creare la dipendenza sbagliata; può causare classi gonfiate, e può essere difficile da navigare e capire.

Alla fine, è tutto su come organizzare fisicamente il nostro codice con più dimensioni di preoccupazioni in uno spazio unidimensionale. Non è un problema banale, è soggettivo e non esiste una panacea.

In particolare, il nostro settore ha ereditato un sacco di regole empiriche che sono state fatte nel secolo scorso sulla base di vincoli tecnici ed economici di quell'epoca. Ad esempio, gli utensili erano molto limitati; i programmatori erano molto costosi; le applicazioni si sono evolute lentamente.

Alcune di queste regole potrebbero non essere più applicabili oggi.

Answer 6

Non penso che l'instanceof sia un problema per i programmatori che sanno cosa stanno facendo e lo usano per evitare di dover scrivere codice più complicato per aggirarlo. C'è un uso per tutto, e anche un uso improprio.

Detto ciò, la descrizione fornita non richiede l'istanza. Esistono vari modi per implementarlo senza instanceof e (la cosa più importante) la soluzione alternativa deve essere migliore rispetto all'utilizzo di instanceof. Non andare con una soluzione non-instanceof per evitare l'instanceof perché hai sentito che è male.

Penso che per il proprio scenario una soluzione non-instanceof abbia vantaggi nel rendere la soluzione più facilmente estendibile.

for (Item i: items) { 
    if (ItemTypes.WEAPON_ITEM.equals(i.getType)) { 
     processWeaponType(i); 
    } 

} 

o

for (Item i: items) { 
    if (WeaponItem.class.equals(i.getType)) { 
     processWeaponType(i); 
    } 

}