Come evitare il downcasting?

La mia domanda riguarda un caso speciale dell'Animale super class.

1. La mia Animallattina moveForward()e eat().
2. Sealsi estende Animal.
3. Dogsi estende Animal.
4. E c'è una creatura speciale che si estende anche Animalchiamata Human.
5. Humanimplementa anche un metodo speak()(non implementato da Animal).

In un'implementazione di un metodo astratto che accetta Animalvorrei usare il speak()metodo. Ciò non sembra possibile senza fare un downcast. Jeremy Miller ha scritto nel suo articolo che un downcast puzza.

Quale sarebbe una soluzione per evitare il downcasting in questa situazione?

Se hai un metodo che deve sapere se la classe specifica è di tipo Humanper fare qualcosa, allora stai infrangendo alcuni principi SOLID , in particolare:

• Principio aperto / chiuso: se, in futuro, è necessario aggiungere un nuovo tipo di animale in grado di parlare (ad esempio un pappagallo) o fare qualcosa di specifico per quel tipo, il codice esistente dovrà cambiare
• Principio di segregazione dell'interfaccia: sembra che tu stia generalizzando troppo. Un animale può coprire un ampio spettro di specie.

Secondo me, se il tuo metodo prevede un particolare tipo di classe, chiamarlo è un metodo particolare, quindi cambia quel metodo per accettare solo quella classe e non la sua interfaccia.

Qualcosa come questo :

public void MakeItSpeak( Human obj );

e non così:

public void SpeakIfHuman( Animal obj );

Il problema non è che stai effettuando il downcasting, ma che stai eseguendo il downcasting Human. Invece, crea un'interfaccia:

public interface CanSpeak{
    void speak();
}

public abstract class Animal{
    //....
}

public class Human extends Animal implements CanSpeak{
    public void speak(){
        //....
    }
}

public void mysteriousMethod(Animal animal){
    //....
    if(animal instanceof CanSpeak){
        ((CanSpeak)animal).speak();
    }else{
        //Throw exception or something
    }
    //....
}

In questo modo, la condizione non è che l'animale sia Human- la condizione è che possa parlare. Questo significa che mysteriousMethodpuò funzionare con altre sottoclassi non umane Animalpurché implementate CanSpeak.

È possibile aggiungere Communicate to Animal. Il cane abbaia, l'umano parla, il sigillo ... uhh ... non so cosa faccia il sigillo.

Ma sembra che il tuo metodo sia progettato per if (Animal is Human) Speak ();

La domanda che potresti voler porre è: qual è l'alternativa? È difficile dare un suggerimento poiché non so esattamente cosa vuoi ottenere. Ci sono situazioni teoriche in cui il downcasting / upcasting è l'approccio migliore.

In questo caso, l'implementazione predefinita di speak()inAbstractAnimal classe sarebbe:

void speak() throws CantSpeakException {
  throw new CantSpeakException();
}

A quel punto, hai un'implementazione predefinita nella classe Abstract - e si comporta correttamente.

try {
  thingy.speak();
} catch (CantSeakException e) {
  System.out.println("You can't talk to the " + thingy.name());
}

Sì, questo significa che hai i tentativi catturati attraverso il codice per gestire tutti speak , ma l'alternativa a questo è invece if(thingy is Human)racchiudere tutti i discorsi.

Il vantaggio dell'eccezione è che se ad un certo punto hai un altro tipo di cose che parlano (un pappagallo) non dovrai reimplementare tutti i tuoi test.

Il downcasting è talvolta necessario e appropriato. In particolare, è spesso appropriato nei casi in cui si hanno oggetti che possono o meno avere qualche abilità, e si desidera usare quell'abilità quando esiste mentre si maneggiano oggetti senza quell'abilità in qualche modo predefinito. Come semplice esempio, supponiamo che a Stringsia chiesto se è uguale a qualche altro oggetto arbitrario. Affinché uno Stringsia uguale all'altro String, deve esaminare la lunghezza e l'array di caratteri di supporto dell'altra stringa. Se a Stringviene chiesto se è uguale a a , il confronto dovrebbe usare un comportamento predefinito (riportando che l'altro oggetto non è uguale).Dog , tuttavia, non può accedere alla lunghezza di Dog, ma non dovrebbe; invece, se l'oggetto con cui Stringsi suppone che a si paragoni non è aString

Il momento in cui il downcasting dovrebbe essere considerato il più dubbio è quando l'oggetto che viene lanciato è "conosciuto" per essere del tipo giusto. In generale, se un oggetto è noto per essere un Cat, si dovrebbe usare una variabile di tipo Cat, piuttosto che una variabile di tipo Animal, per fare riferimento ad esso. Ci sono momenti in cui questo non sempre funziona, tuttavia. Ad esempio, una Zooraccolta potrebbe contenere coppie di oggetti in slot di matrice pari / dispari, con l'aspettativa che gli oggetti in ciascuna coppia possano agire l'uno sull'altro, anche se non possono agire sugli oggetti in altre coppie. In tal caso, gli oggetti in ciascuna coppia dovrebbero comunque accettare un tipo di parametro non specifico in modo tale che possano, sintatticamente , passare gli oggetti da qualsiasi altra coppia. Quindi, anche se Cat'splayWith(Animal other)metodo avrebbe funzionato solo quando otherera a Cat, Zooavrebbe dovuto essere in grado di passargli un elemento di un Animal[], quindi il suo tipo di parametro avrebbe dovuto essere Animalpiuttosto che Cat.

Nei casi in cui il downcasting sia legittimamente inevitabile, si dovrebbe usare senza scrupoli. La domanda chiave è determinare quando si può ragionevolmente evitare il downcasting ed evitarlo quando sensibilmente possibile.

In un'implementazione di un metodo astratto che accetta Animali, vorrei usare il metodo speak ().

Hai alcune scelte:

• Usa la riflessione per chiamare speakse esiste. Vantaggio: nessuna dipendenza da Human. Svantaggio: ora esiste una dipendenza nascosta dal nome "speak".

• Introdurre una nuova interfaccia Speakere downcast per l'interfaccia. Questo è più flessibile che a seconda di un tipo specifico di calcestruzzo. Ha lo svantaggio che devi modificare Humanper implementare Speaker. Questo non funzionerà se non puoi modificarloHuman

• Abbattuto a Human. Questo ha lo svantaggio che dovrai modificare il codice ogni volta che vuoi parlare un'altra sottoclasse. Idealmente, si desidera estendere le applicazioni aggiungendo codice senza tornare ripetutamente e modificare il vecchio codice.