2016-06-06 8 views
0

Wie java.util.Set<E>, ist es garantiert konsistent? "Konsistent" bedeutet, dass der Autor niemals die aktuellen Schnittstellenmethoden hinzufügt, löscht oder modifiziert. Damit meine Klassen implementiert werden, kann es immer funktionieren.Ist die Schnittstellen-API immer konstant?

In der Tat denke ich über die Risiken nach, wenn ich "Zusammensetzung" anstelle von "Vererbung" verwende. (Effektive Java Artikel 16) Sobald Set API ändert, wird der Code gebrochen.

+3

Was meinen Sie mit "konstant"? – pvg

+2

Und was meinst du mit "immer"? –

Antwort

3

Ist die Schnittstellen-API immer konstant?

Ich nehme an, dass Sie fragen, ob die Set API jemals in einer inkompatiblen Weise geändert werden kann.

Die einzigen Leute, die tatsächlich garantieren können, sind Oracle.

Ich habe keine Garantien (schriftlich) von Oracle gesehen, aber basierend auf der Vergangenheit, gibt es NULL Chance, dass sie die Set API in einer Weise ändern würde, die Binärkompatibilität für Benutzercode beeinträchtigen würde.

Kurz gesagt: Mach dir keine Sorgen. Sicherlich für jede der Standard-Schnittstellen in Java SE.


1 - Die internen Schnittstellen sind eine andere Sache; z.B. alle APIs im sun.* Paketbaum. Jedoch, wenn Sie sie verwenden, das ist einer der risks, die Sie nehmen. In acht nehmen!

+0

Danke. In der Tat denke ich über die Risiken nach, wenn ich "Composition" statt "Inheritance" verwende. (Effektives Java-Objekt 16) Sobald sich die Set-API ändert, wird der Code ungültig. – jinge

+0

@jinge - na ja. Und sobald Schweine fliegen können, sollten wir alle Regenschirme tragen! –

+0

Die verschiedenen Java-Spezifikationen sind die schriftlichen Garantien, zusammen mit den verschiedenen langwierigen Prozessen zum Modifizieren dieser Spezifikationen. Die Binärkompatibilität bricht, die Quellkompatibilität funktioniert fast nie, Verhaltensänderungen treten gelegentlich auf. Oracle veröffentlicht umfangreiche Dokumentationen über solche Änderungen wie hier: http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html Also das ist nicht wirklich nur "basierend auf der Vergangenheit", gibt es Prozesse, um es zu verwalten. – pvg

-1

Ich würde mir keine Sorgen machen. Oracle ist ein Geschäft. Wenn sie eine Änderung an einem ihrer üblichen APIs vorgenommen haben, die dafür gesorgt hat, dass viele Programme nicht mehr funktionieren, wäre das ein großes blaues Auge für sie und würde ihre Marke beschädigen. Sie werden das nicht tun.

Wenn sie eine inkompatible Änderung planen, glaube ich, dass sie damit anfangen würden, jede Methode, die sie in einer zukünftigen Version entfernen möchten, als "veraltet" zu markieren. Es gibt auch eine @Deprecated Annotation, die dazu führt, dass Compiler und IDEs Warnungen generieren. Dies sollte den Benutzern des Features eine faire Warnung geben, dass sie eventuell Änderungen vornehmen müssen. Ich weiß nicht, wie lange Benutzer in der Regel haben, bevor sie müssen eine Änderung vornehmen, aber es scheint mir, dass einige Java-Funktionen als veraltet für mehrere Versionen markiert wurden. (Ausnahme:. roh generische Typen werden als etwas dokumentiert, die verschwinden könnten Also, wenn Sie ein Objekt deklarieren ein Set zu sein, im Gegensatz zu einem Set<SomeType> oder Set<?>, dass konnte Pause in einer zukünftigen Version von Java.)

Ein Vorbehalt: Dies gilt nur für Eigenschaften, die in der API dokumentiert sind. Im Fall von Set, insbesondere, besagt die Dokumentation, dass, wenn Sie durch eine Menge iterieren (z. B. for (element : mySet)), die Reihenfolge undefiniert ist, es sei denn, die tatsächliche Menge ist eine Implementierung, die besagt, dass die Reihenfolge definiert ist. Insbesondere wird es für eine HashSet undefiniert sein. Das bedeutet, wenn Sie absichtlich oder unabsichtlich Code schreiben, der nur funktioniert, wenn die Ergebnisse in einer bestimmten Reihenfolge ausgegeben werden, kann Ihr Code in der nächsten Version beschädigt werden.

EDIT: Zur Frage, ob Methoden zu einer Schnittstelle hinzugefügt werden könnten: Beachten Sie, dass Methoden nicht das Hinzufügen normalen Code nicht bricht, die bereits bereitgestellte Objekte verwendet, die Instanzen der Schnittstelle sind, aber es könnte Code brechen, implementiert die Schnittstelle. Für Schnittstellen, die hauptsächlich bereitgestellt werden, damit Benutzercode sie implementieren kann (z. B. Runnable, funktionale Schnittstellen), könnte das Hinzufügen von Methoden (außer default Methoden) viel Code zerstören, also nehme ich an, dass sie das Hinzufügen von Methoden vermeiden würden Grund. (Wenn sie eine Methode hinzufügen wollten, könnten sie eine neue Subschnittstelle definieren.) Für die Auflistungsklassen wie Set ist es etwas weniger klar, da es für Code normaler ist, eine der Implementierungen zu verwenden, die Java bereits bietet; Die eigene Implementierung zu entwickeln scheint ziemlich ungewöhnlich. Im Gegensatz zu meiner ersten Version dieser Antwort konnte ich jedoch keine Fälle finden, bei denen eine nicht standardmäßige Methode zu einer dieser Schnittstellen hinzugefügt wurde.

+0

Wenn mein Programm eine Klasse hat MySet implementiert Set . Dann fügen Sie in der nächsten Ausgabe Set eine Methode mit dem Namen 'newMethod' hinzu, während Myset diese nicht überschreibt. Es wird meinen Code nicht brechen? – jinge

+0

Tut mir leid, ich habe nicht bemerkt, dass Sie über das Schreiben Ihrer eigenen Klasse gesprochen haben, die 'Set' implementiert. (Ich habe deine Frage noch einmal gelesen und denke, dass ich sehe, wo du fragst, aber die Grammatikprobleme machten es schwierig zu verstehen.) Ich füge weitere Informationen hinzu. – ajb

Verwandte Themen