2010-09-07 17 views
15

¿Por qué se permiten miembros protegidos en las clases finales?¿Por qué se permiten los miembros protegidos en las clases finales de Java?

¿No debería ser un error en tiempo de compilación?

Editar: como han señalado las personas, puede obtener el mismo acceso al paquete utilizando el modificador predeterminado en su lugar. Debería comportarse exactamente de la misma manera, porque protected es solo default + subclases, y el modificador final niega explícitamente la creación de subclases, por lo que creo que la respuesta es más que solo proporcionar el mismo acceso al paquete.

+0

Una variante de la pregunta sigue siendo válida: ¿Por qué podemos tener métodos static final privadas? "Privado" implica "final" y "estático", ¿verdad? ¿No es redundante? – gawi

+0

@gawi: No estoy seguro de cómo interpretar su comentario, pero 'privado' ciertamente no implica' static'/'final'. – BalusC

+0

@gawi: Privado implica no virtual, no estático, y no tiene sentido decir que "privado implica final" ya que "final" solo tiene significado con respecto a los métodos heredados. Estoy de acuerdo, ya que no puedo encontrar una razón válida para usar "final" en una declaración de método privado. –

Respuesta

17

El modificador protected es necesario en los métodos que anulen protected métodos de una clase base, sin exponer a los miembros de la public.

En general, podría introducir un montón de reglas innecesarias para prohibir combinaciones inverosímiles (como protected static), pero no ayudaría mucho. No se puede prohibir la estupidez.

+0

Ah, vale. Porque no puede reducir la visibilidad para que sean predeterminados o privados (que es probablemente lo que se pretende en una clase final), para que pueda dejarlos protegidos o exponerlos como público. Aunque en este caso hacerlos predeterminados NO reduce la visibilidad (ya que no es posible la creación de subclases), así que en mi humilde opinión, el compilador Dejo de lloriquear. –

+0

Sí. Debería haber dicho que podrías hacerlos públicos, pero no querrías. En realidad, 'protected' se comporta de manera peculiar si anula en un paquete diferente. No soy fan de 'protected'. –

+0

¡Buen punto, los métodos también son miembros! Sólido contra-ejemplo. –

14

Debido a que se puede acceder a miembros protegidos por otras clases en el mismo paquete, así como subclases.

+6

Ciertamente cierto, aunque si ese es el caso, obtiene el mismo resultado utilizando el acceso predeterminado (paquete), por lo que aún podría ser un error de compilación. Creo que esto es solo más evidencia de que deberían haber mantenido la visibilidad de las subclases y la visibilidad del paquete/clase interna como conceptos completamente separados. ¿Quiénes son para decirme que si una subclase tiene visibilidad, el paquete también debe? –

+0

@Mark: Sí, claramente no se pensó tan bien como podría ser. – skaffman

+0

"miembros protegidos pueden ser accedidos por otras clases en el mismo paquete": ¡¿De verdad ?! Pensé que para eso era el paquete privado. –

9

El modificador protegido también permite el acceso dentro del mismo paquete, no solo a las subclases. Entonces no es completamente sin sentido en una clase final.

+0

30 seconds too sloooooooow :( – Affe

0

Puede argumentar eso, pero de todos modos no hay ningún daño real. Una clase no final también puede tener un miembro protegido, pero no una subclase, tampoco molestará a nadie.

+2

Las cosas que pueden resultar inútiles son buenos candidatos para errores de compilación (las advertencias serían mejores) no porque directamente "molesten" o "lastimen" a alguien/nada, sino porque hay una gran probabilidad de siendo un programador error/error tipográfico –

+0

cómo puede probar que es inútil? cambiar una clase final a una clase no final ni siquiera rompe la compatibilidad binaria. – irreputable

6

El argumento indicado aquí que se puede acceder a los miembros protected por clases del mismo paquete es válido, pero en este caso protected se convierte en igual a la visibilidad predeterminada (paquete-privado), y la pregunta permanece; ¿por qué ambos están permitidos.

supongo que dos cosas:

  • hay necesidad de prohibirlo
  • una clase puede hacerse final temporalmente, hasta que se tome una decisión de diseño. No hay que ir y cambiar todos los modificadores de visibilidad cada vez que se añade o elimina final
+2

+1: Sin embargo, me sorprendió lo rápido que las respuestas "incorrectas" subieron. ¿Le dice algo sobre el conocimiento promedio? – BalusC

-1
package p; 

import java.sql.Connection; 

public final class ProtectedTest { 
    String currentUser; 
    Connection con = null; 

    protected Object ProtectedMethod(){ 
     return new Object(); 
    } 
    public ProtectedTest(){ 
    } 
    public ProtectedTest(String currentUser){ 
     this.currentUser = currentUser; 
    } 
} 

package p; 

public class CallProtectedTest { 
    public void CallProtectedTestMethod() { 
     System.out.println("CallProtectedTestMethod called :::::::::::::::::"); 
     ProtectedTest p = new ProtectedTest(); 
     Object obj = p.ProtectedMethod(); 
     System.out.println("obj >>>>>>>>>>>>>>>>>>>>>>>"+obj); 
    } 
} 

package p1; 

import p.CallProtectedTest; 

public class CallProtectedTestFromp2 { 
    public void CallProtectedTestFromp2Method(){ 
     CallProtectedTest cpt = new CallProtectedTest(); 
     cpt.CallProtectedTestMethod(); 
    } 

    public static void main(String[] args) { 
     CallProtectedTestFromp2 cptf2 = new CallProtectedTestFromp2(); 
     cptf2.CallProtectedTestFromp2Method(); 
    } 
} 
+2

Algunas explicaciones tal vez ? – cheesemacfly

Cuestiones relacionadas