¿Java tiene un modificador de acceso "privado protegido"?


160

He visto algunas referencias que se refieren a un modificador de acceso en Java llamado private protected(ambas palabras juntas):

private protected someMethod() {

}

Una de las páginas que encontré en referencia a esto está aquí . La lección de mi escuela también se refirió a este modificador de acceso (y dijo que existe). Sin embargo, su uso da como resultado un error en el lenguaje Java.

Intenté con variables y métodos y estoy bastante seguro de que no existe, pero quiero una explicación de lo que sucedió. ¿Fue considerado, luego rechazado? ¿O se eliminó en una versión más nueva de Java?

Editar: no estoy buscando información sobre la protectedpalabra clave.


6060
La página que encontró establece un encabezado HTTP "Última modificación" de: lunes, 26 de febrero de 1996 18:14:04 GMT!
G. Sylvie Davies

66
@ Joe Estoy a favor de cerrar las preguntas como engañados cuando sea posible, pero no veo nada sobre un private protectedmodificador combinado allí.
jpmc26

2
@ jpmc26 Consulte "En Java 1.0 había un modificador de acceso adicional, privado protegido". Sin embargo, la respuesta aquí es un resumen mucho mejor de la historia.
Joe

2
@ Joe De hecho, hay una referencia private protecteden esa respuesta, pero no explica por qué o qué le sucedió, de qué trata esta pregunta.
m0skit0

3
¿Alguien más le da miedo que el OP estaba aprendiendo esto en la escuela ... más de 20 años después de que fue eliminado de los Docs? Lección de historia interesante, pero aún un poco de miedo de que la gente está aprendiendo algo que fue retirado antes de Java 1 fue nombrado ...
XaolingBao

Respuestas:


191

Eliminación del modificador de acceso.

Java originalmente tenía el private protectedmodificador, pero se eliminó en JDK 1.0.2 (la primera versión estable , la Java 1.0 que conocemos hoy). Algunos tutoriales sobre JDK 1.0.2 ( aquí y aquí ) dicen lo siguiente:

Nota: La versión 1.0 del lenguaje Java admite cinco niveles de acceso: los cuatro enumerados anteriormente más private protected. El private protectednivel de acceso no es compatible con versiones de Java superiores a 1.0; ya no deberías usarlo en tus programas Java.

Otra respuesta sobre SoftwareEngineering.SE afirma:

Java originalmente tenía un modificador de este tipo. Fue escrito private protectedpero eliminado en Java 1.0.

Ahora eche un vistazo al Historial de versiones de Java :

JDK 1.0

La primera versión se lanzó el 23 de enero de 1996 y se llamó Oak. La primera versión estable, JDK 1.0.2, se llama Java 1.

De esto, podemos concluir que los tutoriales con respecto a la versión 1.0.2 se refieren a la primera versión, JDK 1.0, donde el lenguaje se llamaba Oak, pero el de SoftwareEngineering.SE se refiere a la primera versión estable, JDK 1.0.2 llamada Java 1.0, donde fue eliminado.

Ahora, si intenta buscarlo en la documentación de Java 1.0 , no lo encontrará, porque como se mencionó anteriormente, se eliminó en JDK 1.0.2, también conocido como Java 1.0. Esto se prueba nuevamente cuando mira las horas de "Última modificación" para el enlace que publicó. El enlace que publicó se modificó por última vez en febrero de 1996. Java 1.0 / JDK 1.0.2, cuando private protectedse eliminó, se lanzó después de febrero de 1996 y, según las especificaciones, agosto de 1996.

Motivo de Retiro

Algunas fuentes también explican la razón private protected, como esta . Citar:

¿Qué fue privado protegido?

Al principio, el lenguaje Java permitía ciertas combinaciones de modificadores, uno de los cuales era private protected. El significado de private protectedera limitar la visibilidad estrictamente a las subclases (y eliminar el acceso al paquete). Más tarde, esto se consideró algo inconsistente y demasiado complejo y ya no es compatible. [5]

[5] El significado del protectedmodificador cambió en la versión Beta2 de Java, y la private protectedcombinación apareció al mismo tiempo. Repararon algunos posibles agujeros de seguridad, pero confundieron a muchas personas.

Y SoftwareEngineering.SE también respalda esto, al decir que no valía la pena las inconsistencias y la complejidad adicional, por lo que se eliminó desde el principio.

Interpretación

Mi interpretación de todo esto es que quizás, en los días de Oak, a ambos se les permitía coexistir (de ahí la combinación). Debido a que protectedel significado había cambiado 1 , puede haber sido necesario permitir privatey protectedal mismo tiempo. La introducción se volvió demasiado compleja y no valió la pena, por lo que finalmente se abandonó. En el momento en que Java 1.0 / JDK 1.0.2 llegó, ya se había eliminado y, por lo tanto, no se puede encontrar en la documentación.


1 En la Especificación del lenguaje Oak , Sección 4.10, Acceso a variables y métodos , se observa que el modificador predeterminado era protected:

Por defecto, todas las variables y métodos de una clase están protegidos .

Esto es bastante diferente de lo que tenemos hoy, el acceso predeterminado al paquete. Esto puede haber allanado el camino para la necesidad private protected, porque privateera demasiado restrictivo y protecteddemasiado indulgente.


Estoy seguro de que no vale mucho, pero recuerdo cuándo sucedió (estaba programando cuando era niño y estaba muy interesado en esta nueva cosa de Java por alguna razón) y aunque no puedo encontrar ninguna de las fuentes originales, recuerdo cosas exactamente así cuando los seguí.
Benjamin Gruenbaum

Early on, the Java language allowed for certain combinations of modifiers, ¿Eso significa que había más que solo "Protección Privada"?
XaolingBao

@XaolingBao Bueno, por supuesto, un accesorio es como ningún accesorio :) Los enlaces provistos deben aclarar su pregunta.
m0skit0

52

Hay historias confusas / poco claras:

Uno, de la fuente de Princeton que pones, y también de los archivos del MIT , afirma que:

Nota: La versión 1.0 del lenguaje Java admite cinco niveles de acceso: los cuatro enumerados anteriormente más privado protegido. El nivel de acceso protegido privado no es compatible con versiones de Java superiores a 1.0; ya no deberías usarlo en tus programas Java.

Pero esta característica no se especifica en ninguna documentación oficial para Java 1.0 aquí o aquí .

Supongo que esta característica no llegó a la versión oficial 1.0, ya que la especificación del idioma oficial es de agosto de 1996 y la fuente de Princeton se modificó por última vez en febrero de 1996 .

PD: lástima de Oracle por eliminar los archivos de las versiones anteriores.


Entonces, ¿mi enlace es una versión anterior del mismo contenido? : D

Tal vez la información que falta tiene algo que ver con esa nota que pones.

@AndrewLi Nowhere tampoco se establece como estable en las referencias dadas. Y definitivamente es confuso referirse a 1.0.2 como 1.0 cuando hay un 1.0 real.
m0skit0

10

Como sugiere el enlace que proporcionó en su pregunta, private protectedse usó en element/memberuna clase, cuando desea subclassque pueda acceder al elemento pero mantenerlo oculto de otras clases en él package.

Javasi se compara con C++tiene un concepto adicional de elementos de encapsulación, y ese es un paquete . También se debe entender qué es accesible dentro o fuera de un paquete Javacuando se trata de estos especificadores de acceso como private, public& protected.

Tenga en cuenta que he explicado por qué se utilizó. No en la versión actual, por supuesto.


Mi enlace es para acceder al método. No acceso de miembros.

1
@MarkYisri lo mismo puede usarse también para variables miembro. Los especificadores de acceso no funcionan solo en métodos, sino también en variables miembro. En otras palabras, los especificadores de acceso son conceptos de encapsulación y son independientes de si lo aplica en métodos de miembros o variables de miembros. que se aplica a casi todos los lenguajes orientados a objetos, incluyendo C ++ y Java
programmer_of_the_galaxies

De acuerdo, pero el tutorial (curiosamente) no menciona la protección privada en las variables. Espera y déjame ver si hay una página de variables ...


0

No, no se puede utilizar tanto en privateun protectedconjunto. Tu tutorial es extraño. Lo que tiene es el llamado paquete privado o en acceso de paquete protegido de ot6 referencias. Este es el acceso predeterminado que se habilita cuando no se escribe explícitamente ningún calificador acc6.


3
Sabía que no puedes usarlo. Quiero saber qué le sucedió, que las otras respuestas explican mejor.

44
Bueno, el enlace es de 1996, así que dado que el desarrollo de Java acababa de comenzar aproximadamente un año antes, el contenido del enlace no es realmente tan extraño: D
Keiwan

66
Buen punto sobre la fecha de cada documento. Respondí la pregunta mientras llegaba mi tren y la escribí usando el teléfono, lo siento si la respuesta no se descarriló lo suficiente. Solo quería ayudar ...
AlexR

66
@AlexR su error de ortografía descarrilado es en realidad un juego de palabras (tren). Me acabo de dar cuenta. : D

1
@MarkYisri, detallado. Escribir usando el teléfono no es la mejor manera de publicar respuestas en SO.
AlexR

-2

El ámbito privado está dentro de la clase existente. En donde Protegido se puede acceder dentro del paquete y la clase extendida por las clases en otros paquetes.

Sin problemas si desea que sus variables / métodos tengan acceso fuera del paquete, debe definirlo como protegido / público, de lo contrario privado o algún otro especificador de acceso.

Por lo general, se puede acceder a los métodos protegidos desde un paquete externo y dentro de subclases, es decir, una clase debe extender la clase respectiva para aprovechar los métodos definidos protegidos.

Los métodos / variables privadas tienen alcance dentro de la clase. No pueden ser accesibles fuera de la clase.

Por lo tanto, no puede definir Private Protected al mismo tiempo.


Esto no respondió la pregunta. Le pregunté por qué no funcionó. Las otras respuestas hacen un trabajo mucho mejor al responder la pregunta.

Para aclarar más, sé que ya no funciona, pero las otras respuestas explican por qué y qué sucedió en el pasado. El tuyo no.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.