Fälschen abstrakter Methoden mithilfe von Ausnahmen in Java

Question

Diese Frage wurde mir gestellt und ich bin ehrlich gesagt ratlos:

Anstatt abstrakte Methoden zu schreiben, könnten wir versuchen, sie mit Ausnahmen zu fälschen, wie folgt:

public int someMethod(int someparameter) {
    throws new RuntimeException("unimplemented");
}

Was wäre der Zweck, dies zu tun, und kann jemand ein Codebeispiel für eine abstrakte Methode bereitstellen, die oben zu fälschen versucht?Jede Hilfe wird sehr geschätzt.Danke schön.

Answer 1

Mir fällt ein (möglicherweise) gültiger Anwendungsfall ein:Sie haben eine abstrakte Klasse und eine Reihe anderer Klassen in Ihrem Projekt, die es erweitert haben.(Oder die abstrakte Klasse befindet sich in einer Open-Source-Bibliothek, sodass Sie keine Ahnung haben, welche anderen Klassen im gesamten Universum daraus erweitert werden könnten.) Nun finden Sie, dass es nützlich ist, dieser Klasse neue abstrakte Methoden hinzuzufügen.Aber wenn Sie hinzufügen abstract Wenn Sie der Klasse Methoden hinzufügen, wird dadurch jede andere Klasse beschädigt, die sie bereits erweitert hat, da diese Klassen geändert werden müssen, um Überschreibungen für die neuen Methoden zu enthalten.Daher kann ich mir vorstellen, dass es in manchen Fällen praktikabler sein könnte, sie als nicht abstrakte Methoden hinzuzufügen und sie für alle Fälle Ausnahmen auslösen zu lassen neu Die Klasse, die sie erweitert, verwendet die neuen Methoden, vergisst jedoch, eine überschreibende Methode zu schreiben.Es wird nicht zur Kompilierungszeit abgefangen, aber es könnte zumindest beim Testen abgefangen werden.

Ich bin mir nicht sicher, wie legitim dieser Grund ist, da es auch möglich ist, eine neue abstrakte Klasse zu definieren NewImprovedWhatever das erweitert die alte, um die neuen Methoden zu enthalten.Das kann jedoch eigene Wartungsherausforderungen mit sich bringen.Ich bin mir nicht sicher.

Mir ist aufgefallen, dass Java eine abstrakte Klasse definiert java.net.SocketImpl, das zwei nicht abstrakte Methoden enthält, shutdownInput() Und shutdownOutput(), dessen Standardimplementierung darin besteht, eine Ausnahme auszulösen:

protected void shutdownInput() throws IOException {
  throw new IOException("Method not implemented!");
}

Aus den Kommentaren geht hervor, dass sie in 1.3 hinzugefügt wurden. Vielleicht ist das genau der Grund, warum es auf diese Weise gemacht wurde, d. h.Keine Änderung anderer Klassen erforderlich, die bereits erweitert wurden SocketImpl.Aber ich weiß es nicht genau.

Auf jeden Fall wäre ein Design wie dieses sicherlich wirklich schlechter Code, wenn die Klasse von Grund auf so entworfen würde.Aber die netten O-O-Konzepte, die wir im Unterricht lernen, sind in der Praxis nicht immer so gut, wenn vorhandener Code geändert werden muss.

Answer 2

Ich habe manchmal geworfen nicht supportedoperationException vonEine Methode, deren Funktionalität noch nicht implementiert wurde.(Es gibt auch einen NotimplementedException in Apache Commons , eine Unterklasse von nicht supportedoperationException.) Dies war immer als Platzhalter und eine Nachricht an andere, die mit der zugehörigen Klasse oder des Dienstes verwendet, die die Methode noch nicht vollständig ist.Ein solcher Code hat es jedoch nie zur Herstellung gemacht.

Answer 3

Der Zweck, dies zu tun, wäre, schlechter Code absichtlich zu schreiben.
Wenn man seine Leser verwirren will und möchte, dass sie die Qual des Gehens durch ihren Code spüren, dann schreibt man einen solchen Code.
Es zeigt auch das Fehlen der Gestaltung von Fähigkeiten im Code.
Eine schlecht geschriebene API hat einen solchen Code.
Tun Sie das nicht.