Ist es in Ordnung, den Methoden einer Schnittstelle, die einen Listener darstellt, Standardimplementierungen hinzuzufügen?

Question

Es gibt eine bestimmte Bibliothek, die ich in meinem Projekt verwende. Diese Bibliothek hat eine Schnittstelle, die ungefähr 15 Methoden hat.

Der Zweck dieser Schnittstelle ist es, einige Ereignisse, die in der Bibliothek generiert werden, zu abonnieren. Eine Listener-Klasse in einer Anwendung kann diese Schnittstelle implementieren und sich selbst als Listener in der Bibliothek registrieren, um Ereignisse zu empfangen.

Alle Methoden in dieser Schnittstelle sind tatsächlich Ereignisse. Es kann Listener geben, die nur ein oder zwei Ereignisse von vielen Ereignissen in der Schnittstelle empfangen müssen. Obwohl ein Listener nur an wenigen Ereignissen interessiert ist, muss der Listener beim Erweitern der Schnittstelle alle Methoden implementieren.

Also bat ich den Entwickler dieser Bibliothek, den Methoden in der Schnittstelle leere Standardimplementierungen hinzuzufügen.

Aber der Bibliotheksentwickler weigert sich, Standardimplementierungen hinzuzufügen, die besagen, dass dies gegen Java-Best Practices verstößt und die Verwendung von Standardimplementierungen in Schnittstellenmethoden gegen den Zweck von Schnittstellen verstößt.

Aber, wie ich verstehen kann, gibt eine Methode in dieser Schnittstelle keine Aktion an, die ein Implementierer dieser Schnittstelle in der Lage sein sollte. Eine Methode in dieser Schnittstelle definiert eher ein Ereignis, an dem ein Implementierer interessiert sein könnte. Daher kann ich keinen klaren Grund sehen, keine Standardimplementierungen hinzuzufügen.

Also, das Hinzufügen von Standardimplementierungen zu dieser Schnittstelle brechen die Java-Best Practices?

Answer 1

Aber die Bibliothek Entwickler weigern Standardimplementierungen hinzuzufügen, besagen, dass es Java-Best Practices verletzen würde und mit dem Standard Implementierungen in Interface-Methoden gehen gegen den Zweck der Schnittstellen.

Dieses Argument war gültig, bis Standardschnittstellenmethoden eingeführt wurden. Nun müsste Ihr Kollege argumentieren, dass die JLS von Java 8 perverse Schnittstellen hat und das JDK nun Klassen enthält, die dem Zweck von Schnittstellen entgegenstehen. Dennoch ist dies ein praktikabler äußerer Standpunkt, aber fruchtlos.

Sie können die Diskussion einfach vermeiden, indem Sie eine eigene Schnittstelle von der Bibliotheksschnittstelle ableiten und leere Standardimplementierungen für alle geerbten Methoden bereitstellen.

public interface MyInterface extends LibraryInterface { 
    @Override default public void event1() { 
    } 

    ... 
} 

Oder Sie beide können das folgende Design überprüfen, die mir zweifelhaft scheint und was zu Ihrer Diskussion über Standardmethode in Schnittstellen:

Auch wenn ein Zuhörer ist nur interessiert in wenigen Veranstaltungen , Listener muss alle Methoden implementieren, wenn die Schnittstelle erweitert wird.

Eine Lösung könnte sein, die große Schnittstelle in viele kleinere aufzuteilen.

Answer 2

Da Standardmethoden uns ermöglichen, neue Funktionalitäten zu Schnittstellen hinzuzufügen, ohne die Klassen zu brechen, die diese Schnittstelle implementieren, ist es definitiv keine gute Übung, weil es die Tugenden von Schnittstellen und abstrakten Klassen kombiniert, aber da das keine Option ist würde stark vorschlagen, dass Sie Ihre eigene skelettale Implementierungsklasse zur Verfügung stellen, da diese "Methodik" überall im Collections Framework in Java verwendet wird, und das ist nur meine bescheidene Meinung.

Answer 3

Der Entwickler der Bibliothek ist falsch (ich traue mich sogar, IMHO wegzulassen).

Einer der Gründe, warum in der Vergangenheit viele Hilfsklassen (sowohl abstrakte als auch konkrete) in Java eingeführt wurden, ist genau das Fehlen von Features wie Standardschnittstellenmethoden (zum Beispiel die Adapterklassen in Swing, die den Sorgen sehr ähneln) fragst du nach).

Wenn nicht missbraucht werden, Mehrfachvererbung ist wünschenswert, in einigen Situationen und, wie wir alle wissen, durch eine ‚Helfer‘ Klasse in Java erweitern wir die Möglichkeit, von irgendetwas anderes erben werden verlieren.

Eigentlich ist dies in den offiziellen Java tutorial erwähnt wird im Abschnitt „Abstrakte Klassen an Schnittstellen im Vergleich“:

Betrachten Schnittstellen zu verwenden, wenn eine dieser Aussagen auf Ihre Situation zutreffen:

• Sie erwarten Sie, dass nicht verwandte Klassen Ihre Schnittstelle implementieren würden. Zum Beispiel sind die Schnittstellen Comparable und Clonable von vielen nicht verwandten Klassen implementiert.
• Sie möchten das Verhalten eines bestimmten Datentyps angeben, aber nicht darauf achten, wer sein Verhalten implementiert.
• Sie möchten die mehrfache Vererbung des Typs nutzen.

Der zweite und der dritte Punkt sind die perfekte Ergänzung für Ihren Anwendungsfall, denke ich.