Java abstrakte Schnittstelle

Betrachten Sie ein Beispiel (das in Java kompiliert wird)

public abstract interface Interface {
    public void interfacing();
    public abstract boolean interfacing(boolean really);
}

Warum muss eine Schnittstelle abstrakt "deklariert" werden? Gibt es andere Regeln, die für eine abstrakte Schnittstelle gelten?

Endlich: Wenn abstractes veraltet ist, warum ist es in Java enthalten? Gibt es eine Geschichte für abstrakte Schnittstelle?

Warum muss eine Schnittstelle abstrakt "deklariert" werden?

Es ist nicht.

public abstract interface Interface {
       \___.__/
           |
           '----> Neither this...

    public void interfacing();
    public abstract boolean interfacing(boolean really);
           \___.__/
               |
               '----> nor this, are necessary.
}

Schnittstellen und ihre Methoden sind implizit abstractund das Hinzufügen dieses Modifikators macht keinen Unterschied.

Gibt es andere Regeln, die für eine abstrakte Schnittstelle gelten?

Nein, es gelten dieselben Regeln. Die Methode muss von jeder (konkreten) implementierenden Klasse implementiert werden.

Wenn Abstract veraltet ist, warum ist es in Java enthalten? Gibt es eine Geschichte für abstrakte Schnittstelle?

Interessante Frage. Ich habe die erste Ausgabe von JLS ausgegraben und selbst dort steht "Dieser Modifikator ist veraltet und sollte nicht in neuen Java-Programmen verwendet werden" .

Okay, noch weiter graben ... Nachdem ich auf zahlreiche defekte Links gestoßen war, gelang es mir, eine Kopie der ursprünglichen Oak 0.2- Spezifikation (oder des "Handbuchs") zu finden. Sehr interessante Lektüre muss ich sagen, und insgesamt nur 38 Seiten! :-)

Unter Abschnitt 5, Schnittstellen, finden Sie das folgende Beispiel:

public interface Storing {
    void freezeDry(Stream s) = 0;
    void reconstitute(Stream s) = 0;
}

Und am Rande steht

In Zukunft wird der Teil "= 0" der Deklarationsmethoden in Schnittstellen möglicherweise nicht mehr angezeigt.

Angenommen, =0durch das abstractSchlüsselwort ersetzt wurde, vermute ich, dass dies abstractirgendwann für Schnittstellenmethoden obligatorisch war!

In Verbindung stehender Artikel: Java: Abstrakte Schnittstellen und abstrakte Schnittstellenmethoden

Es ist nicht notwendig, es ist optional, genau wie publicbei Schnittstellenmethoden.

Siehe die JLS dazu:

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html

9.1.1.1 abstrakte Schnittstellen Jede Schnittstelle ist implizit abstrakt. Dieser Modifikator ist veraltet und sollte nicht in neuen Programmen verwendet werden.

Und

9.4 Abstrakte Methodenerklärungen

[...]

Aus Gründen der Kompatibilität mit älteren Versionen der Java-Plattform ist es zulässig, den abstrakten Modifikator für in Schnittstellen deklarierte Methoden redundant anzugeben.

Es ist erlaubt, aber aus Stilgründen wird dringend davon abgeraten, den öffentlichen Modifikator für Schnittstellenmethoden redundant anzugeben.

Es ist nicht erforderlich, die Schnittstelle abstrakt zu deklarieren.

Genau wie das Deklarieren all dieser Methoden als öffentlich (was sie bereits sind, wenn die Schnittstelle öffentlich ist) oder abstrakt (was sie bereits in einer Schnittstelle sind) ist redundant.

Niemand hält dich jedoch auf.

Andere Dinge, die Sie explizit angeben können, aber nicht müssen:

• Rufen Sie super () in der ersten Zeile eines Konstruktors auf
• extends Object
• vererbte Schnittstellen implementieren

Gibt es andere Regeln, die für eine abstrakte Schnittstelle gelten?

Eine Schnittstelle ist bereits "abstrakt". Das erneute Anwenden dieses Schlüsselworts macht absolut keinen Unterschied.

Seien Sie sich bewusst, dass es im Frühling keine akademische Bedeutung hat. Die abstrakte Oberfläche ist eine Warnung an den Entwickler, sie nicht zu verwenden @Autowired. Ich hoffe, dass Spring / Eclipse @Autowireddieses Attribut betrachtet und vor dessen Verwendung warnt / scheitert.

Ein echtes Beispiel: @Service-Proxy unter @Transnational zu einem @Repository müssen dieselben grundlegenden Methoden verwenden, sie sollten jedoch unterschiedliche Schnittstellen verwenden, die diese abstrakte Schnittstelle aufgrund von erweitern @Autowired. (Ich nenne das XXXSpec-Schnittstelle)

Jede Schnittstelle ist implizit abstrakt.
Dieser Modifikator ist veraltet und sollte nicht in neuen Programmen verwendet werden.

[Die Java-Sprachspezifikation - 9.1.1.1 abstractSchnittstellen]

Beachten Sie auch, dass die Methoden der Schnittstellenmitglieder implizit sind public abstract.
[Die Java-Sprachspezifikation - 9.2 Schnittstellenmitglieder]

Warum sind diese Modifikatoren implizit? Es gibt keinen anderen Modifikator (nicht einmal den Modifikator ' kein Modifikator '), der hier nützlich wäre, sodass Sie ihn nicht explizit eingeben müssen.

Es ist nicht notwendig. Es ist eine Eigenart der Sprache.

Dies ist nicht erforderlich, da Schnittstellen standardmäßig abstrakt sind, da alle Methoden in einer Schnittstelle abstrakt sind.

Eine abstrakte Schnittstelle ist zumindest theoretisch nicht so überflüssig, wie jeder zu sagen scheint.

Eine Schnittstelle kann ebenso wie eine Klasse erweitert werden. Wenn Sie eine Schnittstellenhierarchie für Ihre Anwendung entwerfen, verfügen Sie möglicherweise über eine Basisschnittstelle. Sie erweitern andere Schnittstellen von, möchten diese jedoch nicht als Objekt an sich.

Beispiel:

public abstract interface MyBaseInterface {
    public String getName();
}

public interface MyBoat extends MyBaseInterface {
    public String getMastSize();
}

public interface MyDog extends MyBaseInterface {
    public long tinsOfFoodPerDay();
}

Sie möchten nicht, dass eine Klasse das MyBaseInterface implementiert, sondern nur die beiden anderen, MMyDog und MyBoat, aber beide Schnittstellen teilen sich die MyBaseInterface-Schnittstelle, haben also eine 'name'-Eigenschaft.

Ich weiß, dass es ein bisschen akademisch ist, aber ich dachte, einige könnten es interessant finden. :-)

In diesem Fall ist es wirklich nur ein "Marker", um den Implementierern der Schnittstelle zu signalisieren, dass sie nicht für die eigenständige Implementierung ausgelegt ist. Ich sollte darauf hinweisen, dass ein Compiler (zumindest die sun / ora 1.6, mit der ich es versucht habe) eine Klasse kompiliert, die eine abstrakte Schnittstelle implementiert.

Nun, 'Abstract Interface' ist ein lexikalisches Konstrukt: http://en.wikipedia.org/wiki/Lexical_analysis .

Es wird vom Compiler benötigt, man kann auch schreiben interface.

Lassen Sie sich nicht zu sehr auf das lexikalische Konstrukt der Sprache ein, da sie es möglicherweise dort abgelegt haben, um eine Mehrdeutigkeit der Kompilierung zu beheben, die während des Kompilierungsprozesses als Sonderfälle bezeichnet wird, oder um eine gewisse Abwärtskompatibilität zu erzielen. Versuchen Sie, sich auf das lexikalische Kernkonstrukt zu konzentrieren.

Die Essenz von `interface besteht darin, ein abstraktes Konzept (Idee / Denken / Denken höherer Ordnung usw.) zu erfassen, dessen Implementierung variieren kann ... das heißt, es kann mehrere Implementierungen geben.

Eine Schnittstelle ist ein reiner abstrakter Datentyp, der die Merkmale des Objekts darstellt, das erfasst oder dargestellt wird.

Merkmale können durch Raum oder Zeit dargestellt werden. Wenn sie durch Leerzeichen (Speicher) dargestellt werden, bedeutet dies, dass Ihre konkrete Klasse ein Feld und eine Methode / Methoden implementiert, die auf diesem Feld oder nach Zeit arbeiten, was bedeutet, dass die Aufgabe der Implementierung des Features rein rechnerisch ist (erfordert mehr CPU-Uhren für die Verarbeitung), so dass Sie einen Kompromiss zwischen Raum und Zeit für die Implementierung von Features haben.

Wenn Ihre konkrete Klasse nicht alle Funktionen implementiert, wird sie wieder abstrakt, weil Sie eine Implementierung Ihres Gedankens oder Ihrer Idee oder Abstraktheit haben, diese jedoch nicht vollständig ist. Sie geben sie nach abstractKlasse an.

Eine konkrete Klasse ist eine Klasse / Gruppe von Klassen, die die Abstraktheit, die Sie versuchen, die Klasse XYZ zu erfassen, vollständig erfasst.

So ist das Muster

Interface--->Abstract class/Abstract classes(depends)-->Concrete class