Java: Ersetzen einer Unterklasse/Unterart eines Parameters beim Überschreiben einer Methode?

Question

Also habe ich diese Frage schon einmal gestellt, aber ich hatte einen Fehler im Code, den die meisten Leute aufgriffen, anstatt das Problem selbst.

Wie auch immer, ich versuche, eine Interface-Methode in einer Klasse zu überschreiben. Ich möchte jedoch, dass der Typ des Parameters in der überschreibenden Methode eine Unterklasse des Typs des Parameters ist, wie er in der Methode overriden definiert ist.

Die Schnittstelle ist:

public interface Observer { 
public void update(ComponentUpdateEvent updateEvent) throws Exception; 
} 

Während die Klasse, die diese Methode überschreibt ist:

public class ConsoleDrawer extends Drawer { 

//... 

@Override 
public void update(ConsoleUpdateEvent updateEvent) throws Exception { 
    if (this.componentType != updateEvent.getComponentType()) { 
    throw new Exception("ComponentType Mismatch."); 
    } 
    else { 
    messages = updateEvent.getComponentState(); 
    } 
} 

//... 

} 

ConsoleUpdateEvent eine Unterklasse von ComponentUpdateEvent ist.

Jetzt könnte ich nur die update() -Methode in ConsoleDrawer ein ComponentUpdateEvent als Parameter und dann auf ein ConsoleUpdateEvent werfen, aber ich suche nach einer etwas eleganteren Lösung, wenn möglich. Anyhelp würde geschätzt werden. Vielen Dank.

Answer 1

Sie könnten Folgendes versuchen. Das @Deprecated erzeugt eine Warnung, wenn der Compiler weiß, dass Sie die erste Methode und nicht die zweite aufrufen werden.

@Override @Deprecated 
public void update(ComponentUpdateEvent updateEvent) { 
    // throws a ClassCastException if its not the right type. 
    update((ConsoleUpdateEvent) updateEvent); 
} 

public void update(ConsoleUpdateEvent updateEvent) { 
    messages = updateEvent.getComponentState(); 
} 

BTW: Sie sollten nicht nur Platz Ausnahme auf alles wirft. Es ist sicherlich nicht die beste Praxis.

EDIT: Ich habe eine andere Lösung für dieses Problem implementiert, die gut mit OSGi funktioniert, aber überall funktionieren kann.

Ein Observer registriert sich selbst bei einem Broker und erwartet Methoden mit einer Anmerkung wie ObserverCallback.

z.B.

Im ersten Fall findet der Broker eine Methode mit dem @ObserverCallback, die ein Argument benötigt. Dies ist der einzige Typ, den der Broker übergeben wird. Die zweite Klasse erwartet einen anderen Typ. Beobachter können mehrere Methoden/Typen haben, die es ihnen ermöglichen, verschiedene Nachrichten in verschiedenen Methoden zu verarbeiten, die für diesen Typ geeignet sind. Sie wissen auch, dass Sie niemals einen Datentyp erhalten, den Sie nicht erwarten.

Answer 2

Sie können nicht. Das ist nicht Eiffel. Das Problem ist, dass Sie die Schnittstelle verwenden können, um die Implementierungsmethode mit einem inkompatiblen Typ aufzurufen. Daher sind kovariante Parameter nicht erlaubt. Kontravariante Parameter sind ebenfalls nicht erlaubt, es ist jedoch einfacher, eine Überladung bereitzustellen. Kovarianter Rückgabetyp ist erlaubt (seit 1.5).

Sie die Schnittstelle parametriert werden könnte:

public interface Observer<T extends ComponentEvent> { 
    void update(T event) throws Exception; 
} 

Alternativ können Sie eine aussagekräftigere Schnittstelle:

public interface ConsoleObserver { 
    void update(ConsoleEvent event) throws Exception; 
} 

Answer 3

Going durch OOP-Prinzipien, eine Unterklasse sollte verwendbar sein in genau der gleichen Weise wie die Elternklasse. z.B.

Observer ob = new ConsoleDrawer(); 
ob.update(new ComponentUpdateEvent()); // This needs to work always. 

Wenn jedoch Java war, damit Sie einen Subtyp des Parameters zu verwenden, wenn eine Methode überschreiben, dann wäre es, Ihren Code zu Fällen aussetzen, wo die übergeordnete Methode (in der Unterklasse) den Eingangsparameter ablehnen würde (ComponentUpdateEvent im obigen Fall). Somit wären Sie nie sicher, ob es sicher ist, update() oder nicht auf einer Observer-Referenz aufzurufen.

Daher ist die einzige logische Lösung, den Parent-Class-Parameter zu akzeptieren, type-check es und dann auf den erforderlichen Subtype zu werfen.