Sollten Methoden in einer Java-Schnittstelle mit oder ohne Public Access Modifier deklariert werden?

Sollten Methoden in einer Java-Schnittstelle mit oder ohne publicZugriffsmodifikator deklariert werden ?

Technisch spielt es natürlich keine Rolle. Eine Klassenmethode, die ein implementiert, interfaceist immer public. Aber was ist eine bessere Konvention?

Java selbst ist darin nicht konsistent. Siehe zum Beispiel Collectiongegenüber Comparableoder Futuregegenüber ScriptEngine.

Das JLS macht dies klar:

Es ist zulässig, aber aus Stilgründen wird davon abgeraten, den publicund / oder abstractModifikator für eine in einer Schnittstelle deklarierte Methode redundant anzugeben .

Der öffentliche Modifikator sollte in Java-Interfaces weggelassen werden (meiner Meinung nach).

Da keine zusätzlichen Informationen hinzugefügt werden, wird die Aufmerksamkeit nur von den wichtigen Dingen abgelenkt.

Die meisten Style-Guides empfehlen, dass Sie es weglassen, aber das Wichtigste ist natürlich, dass Sie in Ihrer Codebasis und insbesondere für jede Benutzeroberfläche konsistent sind. Das folgende Beispiel könnte leicht jemanden verwirren, der Java nicht zu 100% fließend spricht:

public interface Foo{
  public void MakeFoo();
  void PerformBar();
}

Trotz der Tatsache, dass diese Frage vor langer Zeit gestellt wurde, würde eine umfassende Beschreibung meiner Meinung nach klarstellen, warum es nicht erforderlich ist, public abstract vor Methoden und public static final vor Konstanten einer Schnittstelle zu verwenden.

Zunächst werden Schnittstellen verwendet, um allgemeine Methoden für eine Reihe nicht verwandter Klassen anzugeben, für die jede Klasse eine eindeutige Implementierung hat. Daher ist es nicht möglich, den Zugriffsmodifikator als privat anzugeben, da andere Klassen, auf die überschrieben werden soll, nicht auf ihn zugreifen können.

Zweitens kann man zwar Objekte eines Schnittstellentyps initiieren, aber eine Schnittstelle wird von den Klassen realisiert, die sie implementieren und nicht vererbt. Und da eine Schnittstelle möglicherweise von verschiedenen nicht verwandten Klassen implementiert (realisiert) wird, die sich nicht im selben Paket befinden, ist der Modifikator für geschützten Zugriff ebenfalls nicht gültig. Für den Zugriffsmodifikator bleibt uns also nur die öffentliche Wahl.

Drittens hat eine Schnittstelle keine Datenimplementierung, einschließlich der Instanzvariablen und -methoden. Wenn es einen logischen Grund gibt, implementierte Methoden oder Instanzvariablen in eine Schnittstelle einzufügen, muss es sich um eine Oberklasse in einer Vererbungshierarchie und nicht um eine Schnittstelle handeln. In Anbetracht dieser Tatsache müssen alle Methoden in der Schnittstelle abstrakt sein, da keine Methode in einer Schnittstelle implementiert werden kann.

Viertens kann Interface nur Konstanten als Datenelemente enthalten, was bedeutet, dass sie endgültig sein müssen und natürlich Endkonstanten als statisch deklariert werden, um nur eine Instanz von ihnen zu behalten. Daher ist das statische Finale auch ein Muss für Schnittstellenkonstanten.

Zusammenfassend lässt sich sagen, dass die Verwendung von public abstract vor Methoden und public static final vor Konstanten einer Schnittstelle gültig ist, aber da es keine anderen Optionen gibt, wird sie als redundant betrachtet und nicht verwendet.

Mit der Einführung von private, static, defaultModifikatoren für Interface - Methoden in Java 8/9, werden die Dinge komplizierter und ich neige dazu zu denken , dass die vollständigen Erklärungen besser lesbar sind (benötigt Java 9 zu kompilieren):

public interface MyInterface {

    //minimal
    int CONST00 = 0;
    void method00();
    static void method01() {}
    default void method02() {}
    private static void method03() {}
    private void method04() {}

    //full
    public static final int CONST10 = 0;
    public abstract void method10();
    public static void method11() {}
    public default void method12() {}
    private static void method13() {}
    private void method14() {}

}

Ich würde es vermeiden, Modifikatoren einzufügen, die standardmäßig angewendet werden. Wie bereits erwähnt, kann dies zu Inkonsistenzen und Verwirrung führen.

Das Schlimmste, was ich gesehen habe, ist eine Schnittstelle mit deklarierten Methoden abstract...

Ich habe Deklarationsmethoden mit dem publicModifikator verwendet, weil dadurch der Code besser lesbar wird, insbesondere bei der Hervorhebung der Syntax. In unserem neuesten Projekt haben wir jedoch Checkstyle verwendet, das eine Warnung mit der Standardkonfiguration für publicModifikatoren für Schnittstellenmethoden anzeigt. Daher habe ich darauf umgestellt, diese zu deaktivieren.

Ich bin mir also nicht sicher, was am besten ist, aber eine Sache, die ich wirklich nicht mag, ist die Verwendung public abstractvon Schnittstellenmethoden. Eclipse tut dies manchmal beim Refactoring mit "Schnittstelle extrahieren".

Ich schreibe immer, was ich verwenden würde, wenn es keine Schnittstelle gäbe, und ich schreibe eine direkte Implementierung, dh ich würde verwenden public.

Ich überspringe es lieber, ich lese irgendwo, dass Schnittstellen standardmäßig sind, publicund abstract.

Zu meiner Überraschung verwendet das Buch - Head First Design Patterns - publicSchnittstellendeklarationen und Schnittstellenmethoden ... das hat mich noch einmal zum Umdenken gebracht und ich bin auf diesem Beitrag gelandet.

Ich denke, redundante Informationen sollten ignoriert werden.

Ich bin mit der populären Antwort nicht einverstanden, dass Öffentlichkeit impliziert, dass es andere Optionen gibt und es daher nicht geben sollte. Tatsache ist, dass es jetzt mit Java 9 und darüber hinaus andere Optionen gibt.

Ich denke stattdessen sollte Java die Angabe von 'public' erzwingen / verlangen. Warum? Weil das Fehlen eines Modifikators überall sonst "Paket" -Zugriff bedeutet und dies als Sonderfall gilt, führt dies zu Verwirrung. Wenn Sie es einfach zu einem Kompilierungsfehler mit einer eindeutigen Meldung machen würden (z. B. "Paketzugriff ist in einer Schnittstelle nicht zulässig."), Werden wir die offensichtliche Unklarheit beseitigen, die sich aus der Option ergibt, "öffentlich" wegzulassen.

Beachten Sie den aktuellen Wortlaut unter: https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.4

"Eine Methode im Hauptteil einer Schnittstelle kann als öffentlich oder privat deklariert werden (§6.6). Wenn kein Zugriffsmodifikator angegeben wird, ist die Methode implizit öffentlich. Es ist zulässig, aber aus Stilgründen wird davon abgeraten, die Öffentlichkeit redundant anzugeben Modifikator für eine Methodendeklaration in einer Schnittstelle. "

Sehen Sie, dass "privat" jetzt erlaubt ist. Ich denke, der letzte Satz hätte aus dem JLS entfernt werden sollen. Es ist bedauerlich, dass das "implizit öffentliche" Verhalten jemals zugelassen wurde, da es nun wahrscheinlich aus Gründen der Abwärtskompatibilität bestehen bleibt und zu der Verwirrung führt, dass das Fehlen des Zugriffsmodifikators "öffentlich" in Schnittstellen und "Paket" an anderer Stelle bedeutet.

Der Grund dafür, dass Methoden in Schnittstellen standardmäßig öffentlich und abstrakt sind, erscheint mir ziemlich logisch und offensichtlich.

Eine Methode in einer Schnittstelle, die standardmäßig abstrakt ist, um die implementierende Klasse zur Bereitstellung einer Implementierung zu zwingen, ist standardmäßig öffentlich, sodass die implementierende Klasse Zugriff darauf hat.

Das Hinzufügen dieser Modifikatoren zu Ihrem Code ist redundant und nutzlos und kann nur zu dem Schluss führen, dass Ihnen Kenntnisse und / oder Verständnis der Java-Grundlagen fehlen.

Es ist total subjektiv. Ich lasse den redundanten publicModifikator weg, da es wie Unordnung erscheint. Wie von anderen erwähnt, ist Konsistenz der Schlüssel zu dieser Entscheidung.

Es ist interessant festzustellen, dass die C # -Sprachendesigner beschlossen haben, dies durchzusetzen. Das Deklarieren einer Schnittstellenmethode als öffentlich in C # ist tatsächlich ein Kompilierungsfehler. Konsistenz ist wahrscheinlich nicht sprachübergreifend wichtig, daher denke ich, dass dies für Java nicht wirklich direkt relevant ist.

Die Benutzer lernen Ihre Benutzeroberfläche anhand der Code-Vervollständigung in ihrer IDE oder in Javadoc und nicht anhand des Lesens der Quelle. Es macht also keinen Sinn, "öffentlich" in die Quelle zu setzen - niemand liest die Quelle.