Ereditarietà e casting: è buono questo java?

Question

Date un'occhiata a questo codice (da here)

abstract class EntityA { 
    AssocA myA; 
    abstract void meet(); 
} 

abstract class AssocA { 
    int something; 
    abstract void greet(); 
} 

class AssocAConcrete extends AssocA { 
    void greet() { 
     System.out.println("hello"); 
    } 
    void salute() { 
     System.out.println("I am saluting.") 
    } 
} 

class EntityAConcrete extends EntityA { 
    void meet() { 
     System.out.println("I am about to meet someone"); 
     ((AssocAConcrete)myA).salute(); 
    } 
} 

Ci sono due alberi di ereditarietà in parallelo, per una classe genitore e una classe associata. Il problema è con la linea 23:

((AssocAConcrete)myA).salute();

è un dolore e non ho questo genere di cose in tutto il mio codice. Anche se questa linea è parte dell'implementazione concreta di Entity, devo ricordarmi che voglio utilizzare l'implementazione concreta di AssocA, AssocAConcrete.

C'è qualche tipo di annotazione per dichiarare tale relazione? O c'è un modo migliore, più colloquiale in Java per esprimere questo design? Grazie!

---

Questo è in risposta a @ Dave, perché voglio mettere un po 'di codice in ...

Interessante! Quindi l'invocazione sarebbe simile a questa:

AssocAConcrete myAssoc = new Assoca(); 
EnitityA<T extends AssocA> myEntity = new EntityA<AssocAConcrete>(); 
myEntity.setAssoc(myAssoc); 
myAssoc.salute(); 

Sì? È davvero fantastico. Penso che lo userò!

Answer 1

vorrei che questo sia molto più ordinato utilizzando farmaci generici ...

abstract class EntityA<T extends AssocA> { 

    // Basically, this means myA is at least an AssocA but possibly more... 
    T myA; 
    abstract void meet(); 
} 

abstract class AssocA { 
    int something; 
    abstract void greet(); 
} 

class AssocAConcrete extends AssocA { 
    void greet() { 
     System.out.println("hello"); 
    } 
    void salute() { 
     System.out.println("I am saluting."); 
    } 
} 

class EntityAConcrete extends EntityA<AssocAConcrete> { 
    void meet() { 
     System.out.println("I am about to meet someone"); 
     myA.salute(); 
    } 
} 

Oltre a evitare la fusione, questo rende anche molto più facile da aggiungere diverse funzionalità nei vostri AssocA implementazioni. Ci dovrebbe sempre essere un modo per fare le cose senza usare implementazioni fittizie (cioè metodi che lanciano semplicemente "NotImplementedException") o casting. Anche se non è sempre facile o vale il tempo di refactoring per farlo. In altre parole, nessuno ti biasimerà per il casting (beh ... forse alcune persone lo faranno ma non puoi accontentare tutti).

EDIT (Note sulla creazione di un'istanza):

Dai commenti @pitosalas' sotto ...

//Won't work...can't call 'new' on abstract class AssocA 
AssocAConcrete myAssoc = new Assoca(); 

//Instead, do this... 
AssocAConcrete myAssoc = new AssocAConcrete(); 

e poi ....

// Again, won't work. T is only declaring the type inside your class/method. 
// When using it to declare a variable, you have to say EXACTLY what you're making, 
// or at least something as exact as the methods you're trying to invoke 
EnitityA<T extends AssocA> myEntity = new EntityA<AssocAConcrete>(); 

//Instead do this... 
EnitityA<AssocAConcrete> myEntity = new EntityAConcrete(); 

// Or this... 
EntityAConcrete myEntity = new EntityAConcrete(); 

E allora questo dovrebbe be good ...

// Assuming this is defined as `public void setAssoc(T newAssoc) {this.myA = newAssoc;}` 
myEntity.setAssoc(myAssoc); 
myAssoc.salute(); 

Answer 2

Sembra sospettoso per me. Non c'è nulla di terribile nel casting, ma in questo caso è possibile risolvere il problema portando il metodo salute in AssocA. Sottoclassi di AssocA possono fornire le loro implementazioni; questo fa parte del beneficio dell'eredità.

Quello che state facendo ora sta dicendo tutte le istanze EntityA hanno un'istanza AssocA, ma poi nel tuo metodo meet che, fondamentalmente, costringono l'istanza AssocA ad essere un'istanza AssocAConcrete. Questa è la parte che è sospetta; perché esiste AssocA se hai davvero bisogno di un AssocAConcrete.

Un'altra opzione (basata sui commenti) è di invocare salute nel metodo greet. In questo modo, la sottoclasse specifica ha specificato il comportamento greet, definito nella superclasse e fa ciò che vuole. In questo caso, salute potrebbe diventare privato o protetto. Un'altra implementazione può facilmente fare qualcosa di diverso, come runLikeHell.

Answer 3

Il problema delle gerarchie di classi parallele è molto reale e fa davvero schifo. L'accoppiamento logico che AssocAConcrete accompagna sempre con EntityAConcrete non può essere espresso con il sistema di tipi.

Non è possibile specializzare il tipo di myA in EntityAConcrete in AssocAConcrete, senza nasconderlo da una superclasse. Penso che il lavoro più vicino a cui è stato rivolto sia stato "Family polymorphism", ma non è mainstream.

Answer 4

Se si dispone di una gran parte del codice in cui si utilizza il riferimento "myA" si potrebbe dichiarare un altro riferimento del genere:

public AssocAConcrete myAConcrete = (AssocAConcrete)myA; 

Ora è possibile utilizzare il nuovo riferimento myAConcrete e accedere alle funzioni del AssocAConcrete Classe.

Se è necessario eseguire questa operazione molto simile a hvgotcodes menzionati, è consigliabile considerare di spostare il metodo fino alla classe AssocA.