Warum sind alle Felder in einer Schnittstelle implizit statisch und endgültig?

Ich versuche nur zu verstehen, warum alle in einer Schnittstelle definierten Felder implizit staticund implizit sind final. Die Idee, Felder zu behalten, staticist für mich sinnvoll, da Sie keine Objekte einer Schnittstelle haben können, aber warum sind sie final(implizit)?

Weiß jemand, warum Java-Designer die Felder in einer Schnittstelle erstellt haben staticund final?

Eine Schnittstelle kann kein Verhalten oder keinen Status haben, da nur ein Interaktionsvertrag und keine Implementierungsdetails angegeben werden sollen. 'Kein Verhalten' wird erzwungen, indem Methoden- / Konstruktorkörper oder statische / Instanzinitialisierungsblöcke nicht zugelassen werden. 'Kein Status' wird erzwungen, indem nur statische Endfelder zugelassen werden. Daher kann die Klasse einen Status (statischen Status) haben, aber der Instanzstatus wird von der Schnittstelle nicht abgeleitet.

Übrigens: Eine Konstante in Java wird durch ein statisches Endfeld definiert (und gemäß Konvention verwendet der Name UPPER_CASE_AND_UNDERSCORES).

Grund zu sein final

Implementierungen können den Wert von Feldern ändern, wenn sie nicht als endgültig definiert sind. Dann würden sie Teil der Implementierung werden. Eine Schnittstelle ist eine reine Spezifikation ohne Implementierung.

Grund zu sein static

Wenn sie statisch sind, gehören sie zur Schnittstelle und nicht zum Objekt oder zum Laufzeittyp des Objekts.

Hier werden einige Punkte beschönigt:

Nur weil Felder in einer Schnittstelle implizit statisch final sind, bedeutet dies nicht, dass sie Konstanten zur Kompilierungszeit oder sogar unveränderlich sein müssen. Sie können zB definieren

interface I {
  String TOKEN = SomeOtherClass.heavyComputation();
  JButton BAD_IDEA = new JButton("hello");
}

(Beachten Sie, dass dies innerhalb einer Annotationsdefinition zu einer Verwirrung von javac führen kann, da das oben Gesagte tatsächlich zu einem statischen Initialisierer kompiliert wird.)

Der Grund für diese Einschränkung ist eher stilistisch als technisch, und viele Leute möchten , dass sie entspannt ist .

Die Felder müssen statisch sein, da sie nicht abstrakt sein können (wie Methoden). Da sie nicht abstrakt sein können, können die Implementierer die unterschiedliche Implementierung der Felder nicht logisch bereitstellen.

Ich denke, die Felder müssen endgültig sein, da auf die Felder möglicherweise von vielen verschiedenen Implementierern zugegriffen wird und sie möglicherweise geändert werden können. Dies kann problematisch sein (da die Synchronisation). Auch um zu vermeiden, dass es erneut implementiert wird (versteckt).

Nur mein Gedanke.

Ich betrachte die Anforderung, dass die Felder endgültig sein müssen, als unangemessen restriktiv und als Fehler der Java-Sprachdesigner. Es gibt Zeiten, z. B. die Baumbehandlung, in denen Sie Konstanten in der Implementierung festlegen müssen, die zum Ausführen von Operationen an einem Objekt des Schnittstellentyps erforderlich sind. Das Auswählen eines Codepfads in der implementierenden Klasse ist ein Problem. Die Problemumgehung, die ich verwende, besteht darin, eine Schnittstellenfunktion zu definieren und sie durch Rückgabe eines Literal zu implementieren:

public interface iMine {
    String __ImplementationConstant();
    ...
}

public class AClass implements iMine {
    public String __ImplementationConstant(){
        return "AClass value for the Implementation Constant";
    }
    ...
}

public class BClass implements iMine {
    public String __ImplementationConstant(){
        return "BClass value for the Implementation Constant";
    }
    ...
}

Es wäre jedoch einfacher, klarer und weniger anfällig für fehlerhafte Implementierungen, diese Syntax zu verwenden:

public interface iMine {
    String __ImplementationConstant;
    ...
}

public class AClass implements iMine {
    public static String __ImplementationConstant =
        "AClass value for the Implementation Constant";
    ...
}

public class BClass implements iMine {
    public static String __ImplementationConstant =
        "BClass value for the Implementation Constant";
    ...
}

Spezifikation, Verträge ... Die Maschinenanweisung für den Feldzugriff verwendet die Objektadresse plus Feldversatz. Da Klassen viele Schnittstellen implementieren können, gibt es keine Möglichkeit, ein nicht endgültiges Schnittstellenfeld so zu gestalten, dass es in allen Klassen, die diese Schnittstelle erweitern, denselben Offset aufweist. Daher muss ein anderer Mechanismus für den Feldzugriff implementiert werden: zwei Speicherzugriffe (Feldversatz abrufen, Feldwert abrufen) anstelle von einem plus Beibehaltung einer virtuellen Feldtabelle (analog zur virtuellen Methodentabelle). Vermutlich wollten sie jvm nicht für Funktionen komplizieren, die einfach über vorhandene Methoden simuliert werden können.

In Scala können wir Felder in Schnittstellen haben, obwohl sie intern wie oben erläutert implementiert sind (als Methoden).

static::

Alles , was (variable oder Methode) , das ist staticin Java kann aufgerufen werden , Classname.variablenameoder Classname.methodnameoder direkt. Es ist nicht obligatorisch, es nur unter Verwendung des Objektnamens aufzurufen.

In der Schnittstelle können Objekte nicht deklariert werden und staticermöglichen das Aufrufen von Variablen nur über den Klassennamen, ohne dass ein Objektname erforderlich ist.

final::

Es hilft, einen konstanten Wert für eine Variable beizubehalten, da sie in ihren Unterklassen nicht überschrieben werden kann.