Java Polimorfizm: Jak mogę uniknąć wprowadzania parametrów wejściowych?

Question

Załóżmy, że mamy interfejs nadrzędny z funkcją compare().

public interface Parent { 
    public int compare(Parent otherParent); 
} 

Załóżmy, że dzieci child1, Child2, Child3 wdrożenia tego interfejsu Parent

public class Child1 implements Parent { 
    @Override 
    public int compare(Parent other) { 
     Child1 otherChild = (Child1)other; 
    } 
} 

Również używam rodzajowych <T extends Parent> wszędzie indziej w kodzie. Muszę więc porównać dwa obiekty typu T z innych części kodu.

Rozumiem, że jest to zły projekt, ponieważ próbuję typować obiekt nadrzędny w funkcji compare() i nie wiem nawet, czy dane wejściowe są typu Child1.

Jak mogę uniknąć tego typu rzucania podczas używania generycznych?

Answer 1

Nie możesz. Interfejsy Java są dokładnie tym, na co wskazuje nazwa - interfejs dyktujący typy akceptowane; więc musi być dokładnie ten sam podpis metody w czasie kompilacji, jak zdefiniowano w interfejsie.

Tak, odesłanie go z powrotem do typu Dziecko wydaje się złym projektem - ale to naprawdę zły projekt, który Java narzuca, więc to nie twoja wina.

Answer 2

Odpowiedź zależy od tego, jak traktujesz swoją hierarchię dziedziczenia:

• Jeśli klasy pochodne muszą porównać do wystąpień tylko własnej klasy i mogą rzucać błąd podczas przedstawiane z obiektu innej klasy, używaj odlewania, ale chroń je sprawdzając, czy klasy pochodne muszą być porównywane z granicami typów, aby uniknąć rzutowania, wymagana jest bardziej złożona strategia: możesz użyć wzorca podobnego do gościa, aby zaimplementować podwójną wysyłkę wymaganą do wykonania porównania.

Oto próbka realizacja przy użyciu klasy abstrakcyjnej:

// Use this class as the base class of your Child classes 
class AbstractChild implements Parent { 
    @Override 
    public int compare(Parent otherObj) { 
     if (!()) { 
      throw new IllegalStateException("Unexpected implementation of Child"); 
     } 
     AbstractChild other = (AbstractChild)otherObj; 
     return doCompare(other); 
    } 
    protected abstract int doCompare(AbstractChild other); 
    protected abstract int accept(Child1 c1); 
    protected abstract int accept(Child2 c2); 
    protected abstract int accept(Child3 c3); 
} 
class Child1 extends AbstractChild { 
    @Override 
    protected int doCompare(AbstractChild other) { 
     return other.accept(this); 
    } 
    @Override 
    protected int accept(Child1 c1) { 
     // Compare c1 instance to this object 
    } 
    @Override 
    protected int accept(Child2 c2) { 
     // Compare c2 instance to this object 
    } 
    @Override 
    protected int accept(Child3 c3) { 
     // Compare c3 instance to this object 
    } 
} 
class Child2 extends AbstractChild { 
    @Override 
    protected int doCompare(AbstractChild other) { 
     return other.accept(this); 
    } 
    @Override 
    protected int accept(Child1 c1) { 
     // Compare c1 instance to this object 
    } 
    @Override 
    protected int accept(Child2 c2) { 
     // Compare c2 instance to this object 
    } 
    @Override 
    protected int accept(Child3 c3) { 
     // Compare c3 instance to this object 
    } 
} 
class Child3 extends AbstractChild { 
    @Override 
    protected int doCompare(AbstractChild other) { 
     return other.accept(this); 
    } 
    @Override 
    protected int accept(Child1 c1) { 
     // Compare c1 instance to this object 
    } 
    @Override 
    protected int accept(Child2 c2) { 
     // Compare c2 instance to this object 
    } 
    @Override 
    protected int accept(Child3 c3) { 
     // Compare c3 instance to this object 
    } 
} 

Jedyny odlew w tym podejściu jest na poziomie klasy abstrakcyjnej. Implementacje rzeczywistej logiki porównania są zawarte w metodach accept, gdzie dokonuje się porównania między dwoma obiektami znanego typu.

Answer 3

Nie można tego uniknąć w ogólnym przypadku. Jednakże, jeżeli liczba klas potomnych zostanie rozwiązany, można zastosować coś zbliżonego do odwiedzający uniknąć odlewania kosztem pisać więcej kod:

interface Parent { 
    int compare(Parent p); 
    protected int compareWith(Child1 c); 
    protected int compareWith(Child2 c); 
    protected int compareWith(Child3 c); 
} 

class Child1 implements Parent { 
    @Override int compare(Parent p) { 
     return p.compareWith(this); 
    } 
    @Override int compareWith(Child1 c) { 
     //specific code to child1 
    } 
    @Override int compareWith(Child2 c) { 
     //specific code to child2 
    } 
    @Override int compareWith(Child3 c) { 
     //specific code to child3 
    } 
} 
// and so on for the other children 

ten unika casting, ale nie jestem pewien, że dodatkowy wysiłek jest wart tego w przypadku, który tu przedstawiłeś.

Answer 4

Dlaczego nie to?

interface Parent<T extends Parent<?>> { 
    int compare(T type); 
} 

class Child1 implements Parent<Child1>{ 

    @Override 
    public int compare(Child1 type) { 
     return 0; 
    } 
} 

Edit: Aby zapewnić prawidłowe użytkowanie można użyć

interface Parent<T extends Parent<T>>{ /* ... */ } //instead of wildcard 

Ale szczerze mówiąc, że „pętla” nie wygląda całkiem, a ponieważ rodzajowych Java nie działa przy starcie (more information), są one w istocie syntaktycznym cukrem dla tej samej obsady, którą nazwałeś "złym projektem", więc nie sądzę, żeby twoje obecne podejście było złe.

Answer 5

Wzór, który tam opisałeś, to dokładnie wzór Comparable. W rzeczywistości należy rozważyć pominięcie interfejsu Parent i zastąpić go numerem Comparable.

Interfejs Comparable i jego zastosowań pokazują również, w jaki sposób ten może być rozwiązany: Typ może być podana jako parametr, aby upewnić się, że tylko typ dopasowania mogą być przekazywane do metody compare:

interface Parent<T> { 
    int compare(T that); 
} 

class Child1 implements Parent<Child1> { 
    @Override 
    public int compare(Child1 that) { 
     ... 
    } 
} 

We wszystkich innych przypadkach, to przynajmniej trzeba myśleć o tym, co powinno się zdarzyć, gdy różne Child wyraĹĽenie -lekcje porównywane są do siebie:

Child1 c1 = new Child1(); 
Child2 c2 = new Child2(); 

// Should this be possible? What should happen here? 
// How should different child classes be compared? 
c1.compare(c2);