Verfügt Java über einen "privat geschützten" Zugriffsmodifikator?

160

Ich habe einige Referenzen gesehen, die sich auf einen Zugriffsmodifikator in Java beziehen, der aufgerufen wird private protected(beide Wörter zusammen):

private protected someMethod() {

}

Eine der Seiten, die ich gefunden habe, ist hier . Meine Schulstunde bezog sich auch auf diesen Zugriffsmodifikator (und sagte, dass er existiert). Die Verwendung führt jedoch zu einem Fehler in der Java-Sprache.

Ich habe es sowohl mit Variablen als auch mit Methoden versucht und bin mir ziemlich sicher, dass es nicht existiert, aber ich möchte eine Erklärung dessen, was passiert ist. Wurde es in Betracht gezogen und dann abgelehnt? Oder wurde es in einer neueren Version von Java entfernt?

Bearbeiten: Ich suche keine Informationen über das protectedSchlüsselwort.


quelle
60
Die Seite, die Sie gefunden haben, enthält einen HTTP-Header "Last-Modified" von: Mon, 26 Feb 1996 18:14:04 GMT!
G. Sylvie Davies
6
@Joe Ich bin alle dafür, Fragen als Dupes zu schließen, wenn möglich, aber ich sehe dort nichts über einen kombinierten private protectedModifikator.
jpmc26
2
@ jpmc26 Siehe "In Java 1.0 gab es einen zusätzlichen Zugriffsmodifikator, privat geschützt." Die Antwort hier ist jedoch eine viel bessere Zusammenfassung der Geschichte.
Joe
2
@ Joe Es gibt zwar einen Verweis private protectedin dieser Antwort, aber es erklärt nicht, warum oder was damit passiert ist, worum es bei dieser Frage geht.
m0skit0
3
Findet es sonst noch jemand beängstigend, dass das OP dies in der Schule gelernt hat ... über 20 Jahre nachdem es aus den Dokumenten entfernt wurde? Interessante Geschichtsstunde, aber immer noch ein bisschen beängstigend, dass Leute etwas lernen, das entfernt wurde, bevor Java 1 benannt wurde ...
XaolingBao

Antworten:

191

Entfernen des Zugriffsmodifikators

Java hatte ursprünglich den private protectedModifikator, wurde jedoch in JDK 1.0.2 (der ersten stabilen Version, Java 1.0, die wir heute kennen) entfernt. In einigen Tutorials zu JDK 1.0.2 ( hier und hier ) heißt es:

Hinweis: Die Version 1.0 der Java-Sprache unterstützt fünf Zugriffsebenen: die vier oben aufgeführten plus private protected. Die private protectedZugriffsebene wird in Java-Versionen über 1.0 nicht unterstützt. Sie sollten es nicht mehr in Ihren Java-Programmen verwenden.

Eine weitere Antwort auf SoftwareEngineering.SE lautet:

Java hatte ursprünglich einen solchen Modifikator. Es wurde private protectedin Java 1.0 geschrieben, aber entfernt.

Schauen Sie sich jetzt den Java-Versionsverlauf an :

JDK 1.0

Die erste Version wurde am 23. Januar 1996 veröffentlicht und heißt Oak. Die erste stabile Version, JDK 1.0.2, heißt Java 1.

Daraus können wir schließen, dass sich die Tutorials zu Version 1.0.2 auf die allererste Version, JDK 1.0, beziehen, in der die Sprache Oak hieß, die von SoftwareEngineering.SE jedoch auf die erste stabile Version, JDK 1.0.2, genannt Java 1.0, wo es entfernt wurde.

Wenn Sie nun versuchen, in der Java 1.0-Dokumentation danach zu suchen , werden Sie es nicht finden, da es, wie bereits erwähnt, in JDK 1.0.2, auch bekannt als Java 1.0, entfernt wurde. Dies wird erneut bewiesen, wenn Sie sich die "Zuletzt geänderten" Zeiten für den von Ihnen geposteten Link ansehen. Der von Ihnen veröffentlichte Link wurde zuletzt im Februar 1996 geändert. Als Java 1.0 / JDK 1.0.2 private protectedentfernt wurde, wurde es nach Februar 1996 und gemäß der Spezifikation im August 1996 veröffentlicht.

Grund für die Entfernung

Einige Quellen erklären auch den Grund dafür private protected, wie dieser . Zitieren:

Was war privat geschützt?

Schon früh erlaubte die Java-Sprache bestimmte Kombinationen von Modifikatoren, von denen einer war private protected. Die Bedeutung von private protectedbestand darin, die Sichtbarkeit streng auf Unterklassen zu beschränken (und den Paketzugriff zu entfernen). Dies wurde später als etwas inkonsistent und übermäßig komplex angesehen und wird nicht mehr unterstützt. [5]

[5] Die Bedeutung des protectedModifikators wurde in der Beta2-Version von Java geändert, und die private protectedKombination wurde gleichzeitig angezeigt. Sie haben einige potenzielle Sicherheitslücken ausgebessert, aber viele Menschen verwirrt.

Und das SoftwareEngineering.SE unterstützt dies auch, indem es sagt, dass es die Inkonsistenzen und die zusätzliche Komplexität nicht wert war, so dass es frühzeitig entfernt wurde.

Deutung

Meine Interpretation von all dem ist, dass vielleicht in den Tagen der Eiche beide koexistieren durften (daher die Kombination). Da sich protecteddie Bedeutung von 1 geändert hatte , bestand möglicherweise die Notwendigkeit, dies zuzulassen privateund protectedgleichzeitig. Die Einführung wurde zu komplex und war es nicht wert und wurde daher am Ende fallen gelassen. Zum Zeitpunkt der Einführung von Java 1.0 / JDK 1.0.2 war es gelöscht worden und daher nicht in der Dokumentation zu finden.


1 In der Oak-Sprachspezifikation , Abschnitt 4.10, Zugriff auf Variablen und Methoden , wird darauf hingewiesen, dass der Standardmodifikator Folgendes war protected:

Standardmäßig sind alle Variablen und Methoden in einer Klasse geschützt .

Dies unterscheidet sich erheblich von dem, was wir heute haben, dem Standardpaketzugriff. Dies mag den Weg für die Notwendigkeit von geebnet haben private protected, weil privatees zu restriktiv und protectedzu nachsichtig war.

Andrew Li
quelle
Ich bin mir sicher, dass es nicht viel wert ist - aber ich erinnere mich, als es passierte (ich habe als Kind programmiert und war aus irgendeinem Grund sehr an dieser neuen Java-Sache interessiert), und obwohl ich keine der Originalquellen finden kann, erinnere ich mich an Dinge genau so, als ich ihnen folgte.
Benjamin Gruenbaum
Early on, the Java language allowed for certain combinations of modifiers, Bedeutet das, dass es mehr als nur "Private Protected" gab?
XaolingBao
@XaolingBao Natürlich ist ein Accessor wie kein Zugang :) Die bereitgestellten Links sollten Ihre Frage klären.
m0skit0
52

Es gibt verwirrende / unklare Geschichten:

Eine aus der von Ihnen angegebenen Princeton-Quelle und auch aus MIT-Archiven besagt:

Hinweis: Die Version 1.0 der Java-Sprache unterstützt fünf Zugriffsebenen: die vier oben aufgeführten plus privat geschützt. Die private geschützte Zugriffsebene wird in Java-Versionen über 1.0 nicht unterstützt. Sie sollten es nicht mehr in Ihren Java-Programmen verwenden.

Diese Funktion ist jedoch in keiner offiziellen Dokumentation für Java 1.0 hier oder hier angegeben .

Ich vermute, dass diese Funktion es nicht in die offizielle Version 1.0 geschafft hat, da die offizielle Sprachspezifikation von August 1996 stammt und die Quelle von Princeton zuletzt im Februar 1996 geändert wurde .

PS: Schande über Oracle, dass die Archive für ältere Versionen entfernt wurden.

m0skit0
quelle
Ist mein Link also eine ältere Version des gleichen Inhalts? : D
Vielleicht haben die fehlenden Informationen etwas mit der Notiz zu tun, die Sie eingegeben haben.
@AndrewLi Nirgendwo wird in den angegebenen Referenzen keiner als stabil angegeben. Und es ist definitiv verwirrend, 1.0.2 als 1.0 zu bezeichnen, wenn es eine tatsächliche 1.0 gibt.
m0skit0
10

Als Link , den Sie in Ihrer Frage zur Verfügung gestellt schlägt private protectedwurde auf einem verwendet element/membereine Klasse, wenn Sie Ihren wollen subclassdas Element in der Lage des Zugang zu sein , aber halten Sie es in seinem von anderen Klassen versteckt package.

Javaim Vergleich zu C++hat ein zusätzliches Konzept der Kapselung von Elementen - und das ist ein Paket . Man sollte auch verstehen , was in innerhalb oder außerhalb eines Pakets zugänglich ist , Javawenn es darum geht, diese Zugang-Planer wie private, publicund protected.

Bitte beachten Sie, dass ich erklärt habe, warum es verwendet wurde. Natürlich nicht in der aktuellen Version

Programmierer_der_Galaxien
quelle
Mein Link ist für den Methodenzugriff. Kein Mitgliederzugriff.
1
@MarkYisri das gleiche kann auch für Mitgliedsvariablen verwendet werden. Zugriffsspezifizierer funktionieren nicht nur für Methoden, sondern auch für Mitgliedsvariablen. Mit anderen Worten, Zugriffsspezifizierer sind Kapselungskonzepte und unabhängig davon, ob Sie sie auf Elementmethoden oder Elementvariablen anwenden. das gilt für fast alle objektorientierten Sprachen einschließlich C ++ & Java
Programmierer_der_Galaxien
Okay, aber das Tutorial erwähnt (interessanterweise) nicht privat geschützt auf Variablen.
0

Nein, Sie können nicht beide verwenden privateeine protectedzusammen. Dein Tutorial ist seltsam. Was Sie haben, ist so genanntes Paket privat oder in ot6 Referenzen paketgeschützter Zugriff. Dies ist der Standardzugriff, der aktiviert wird, wenn kein acc6-Qualifizierer explizit geschrieben wird.

AlexR
quelle
3
Mir war bewusst, dass Sie es nicht verwenden können. Ich möchte wissen, was damit passiert ist, was die anderen Antworten besser erklären.
4
Nun, der Link stammt aus dem Jahr 1996.
Da
6
Guter Punkt zum Datum des Dokuments. Ich beantwortete die Frage, während mein Zug ankam, und schrieb sie per Telefon. Es tut mir leid, wenn die Antwort nicht genug entgleist.
Ich
6
@AlexR Ihr entgleister Rechtschreibfehler ist eigentlich ein Wortspiel (Zug). Gerade bemerkt. : D
1
@ MarkYisri, detailliert. Schreiben mit dem Telefon ist nicht der beste Weg, um Antworten auf SO zu posten.
AlexR
-2

Der private Bereich bezieht sich auf die vorhandene Klasse. Wobei Protected innerhalb von Paketen und Klassen zugänglich sein kann, die durch Klassen in anderen Paketen erweitert wurden.

Wenn Sie nahtlos auf Ihre Variablen / Methoden außerhalb des Pakets zugreifen möchten, müssen Sie diese als geschützt / öffentlich, ansonsten privat oder als andere Zugriffsspezifizierer definieren.

Auf geschützte Methoden kann normalerweise von außerhalb des Pakets und innerhalb von Unterklassen zugegriffen werden, dh eine Klasse muss die jeweilige Klasse erweitern, um geschützte definierte Methoden nutzen zu können.

Private Methoden / Variablen haben einen Gültigkeitsbereich innerhalb der Klasse. Auf sie kann außerhalb der Klasse nicht zugegriffen werden.

Daher können Sie Private Protected nicht gleichzeitig definieren!

Tejas Gowda
quelle
Dies beantwortete die Frage nicht. Ich fragte, warum es nicht funktionierte. Die anderen Antworten beantworten die Frage viel besser.
Zur weiteren Klärung weiß ich, dass es jetzt nicht mehr funktioniert, aber die anderen Antworten erklären, warum und was in der Vergangenheit passiert ist. Dein nicht.