Dziedziczenie i przesyłanie: czy to jest dobra wersja Java?

Question

Spójrz na ten kod (od 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(); 
    } 
} 

Istnieją dwa równoległe spadkowe drzewa, dla klasy dominującej i powiązanej klasy. Problem jest z linii 23:

((AssocAConcrete)myA).salute();

Jest to ból i mam coś takiego w całym moim kodu. Chociaż ta linia jest częścią konkretnej implementacji Entity, muszę przypomnieć, że chcę użyć konkretnej implementacji AssocA, Assocaconcrete.

Czy jest jakiś rodzaj adnotacji, aby zadeklarować ten związek? Czy istnieje lepszy, bardziej kolokwialny sposób Java do wyrażenia tego projektu? Dzięki!

---

Jest to odpowiedź na @Dave, ponieważ chcę, aby umieścić jakiś kod w ...

Ciekawe! Tak więc inwokacja wyglądałaby tak:

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

Tak? To jest naprawdę fajne. Myślę, że go użyję!

Answer 1

Myślę, że jest to dużo neater wykorzystaniem generycznych ...

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(); 
    } 
} 

Oprócz unikania casting, to również sprawia, że ​​znacznie łatwiej dodać inną funkcjonalność w swoich implementacjach AssocA. Zawsze powinien istnieć sposób na robienie rzeczy bez używania fałszywych implementacji (tj. Metod, które po prostu rzucają "NotImplementedException") lub rzutowania. Chociaż nie zawsze jest to łatwe lub warte czasu na refaktoryzację. Innymi słowy, nikt nie będzie cię winić za rzucanie (cóż ... może niektórzy ludzie będą, ale nie możesz zadowolić wszystkich).

EDIT (Uwagi dotyczące instancji):

Z uwagi @pitosalas' poniżej ...

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

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

a potem ....

// 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(); 

I to powinno być dobrym ...

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

Answer 2

Wygląda podejrzanie. Nie ma nic strasznego w castowaniu, ale w tym przypadku możesz rozwiązać problem, wprowadzając metodę salute do. Podklasy AssocA mogą zapewnić ich implementacje; to część korzyści z dziedziczenia.

Co robisz teraz mówi wszystko EntityA przypadki mają instancję AssocA, ale potem w swojej metodzie meet w zasadzie wymusić wystąpienie AssocA być instancją AssocAConcrete. Ta część jest podejrzana; dlaczego istnieje AssocA, jeśli naprawdę potrzebujesz AssocAConcrete.

Inną opcją (opartą na twoich komentarzach) jest wywołanie salute w metodzie greet. W ten sposób określona podklasa ma określone zachowanie greet zdefiniowane w nadklasie i robi to, co chce. W takim przypadku salute może stać się prywatny lub chroniony. Inna implementacja może z łatwością zrobić coś innego, np. runLikeHell.

Answer 3

Problem równoległych hierarchii klas jest bardzo realny i naprawdę do kitu. Logiczne sprzężenie, które AssocAConcrete zawsze jest zgodne z EntityAConcrete, nie może być wyrażone za pomocą systemu typu.

Nie można wyspecyfikować typu myA w EntityAConcrete jako AssocAConcrete, bez ukrywania go przed nadklasą. Myślę, że najbliżej to zajęło się "Family polymorphism", ale to nie jest główny nurt.

Answer 4

Jeśli masz dużą część kodu, w którym używasz określenia „Mya” może zadeklarować inną odniesienie tak:

public AssocAConcrete myAConcrete = (AssocAConcrete)myA; 

teraz można korzystać z nowej odniesienie myAConcrete i dostęp do funkcji AssocAConcrete Klasa.

Jeśli chcesz zrobić to podobnie do hvgotcodes, powinieneś rozważyć przeniesienie metody do klasy AssocA.