Pourquoi la méthode protégée par package n'est-elle pas visible dans le même package?

Question

Supposons que nous avons deux paquets p1 et p2 et des classes p1.M1 étendues par p2.M12 comme suit:

package p1; 

public class M1 { 
    void method1() { 
     System.out.println("Method 1 called"); 
    } 
} 


package p2; 

import p1.M1; 

public class M12 extends M1 { 
    void method2() { 
     System.out.println("Method 2 called"); 
    } 
} 

étendons M12 avec p2.B:

package p2; 

public class B extends M12 { 

    public void doSomething() { 
     method1(); 
     method2(); 
    } 
} 

Cela donne une erreur de compilation comme method1, étant package- protégé dans p1 n'est pas visible dans p2. method2 est visible sans problèmes.

Maintenant, nous allons étendre p2.M12 avec p1.A:

package p1; 

import p2.M12; 

public class A extends M12 { 

    public void doSomething() { 
     method1(); 
     method2(); 
    } 
} 

Ici, je reçois une erreur de compilation pour les deux method2() (ce qui est compréhensible) etmethod1():

Ma question est: pourquoi est le method1 qui est protégé par un paquet dans le paquet p1 n'est pas visible dans la classe A du même paquet p1?

Answer 1

Tout d'abord, ce qui est un membre d'une classe? Les états Java Language Specification

Un corps de classe peut contenir des déclarations de membres de la classe, qui est , les champs (§8.3), les méthodes (§8.4), des classes (§8.5) et les interfaces (§8.5) .

Et de quoi sont-ils composés? Les JLS states

Les membres d'un type de classe sont toutes les caractéristiques suivantes:

• membres de ses héritées superclasse directs (§8.1.4), sauf dans la classe Object, qui a pas de superclasse directe
• Membres hérités de superinterfaces directes (§8.1.5)
• Membres déclarés dans le corps de la classe (§8.1.6)

Il mentionne également

Seuls les membres d'une classe qui sont déclarées protected ou public sont héritées par les sous-classes déclarés dans un paquet autre que celui dans dont la classe est déclarée.

Tout cela est reformulé dans le chapter on Inheritance

Une classe C hérite de ses superclasse directs toutes les méthodes concrètes m (à la fois statiques et d'instance) de la superclasse pour laquelle tous les les suivants sont vrais:

• m est un membre de la superc directe jeune fille de C.
• m est public, protected, ou déclaré avec accès au package dans le même package que C`.
• Aucune méthode déclarée dans C n'a une signature qui est une sous-signature (§8.4.2) de la signature de m.

Les membres de la classe M1 sont method1 (et toutes les méthodes de Object). M12, étant dans un package différent de sa superclasse directe, M1, n'hérite pas method1. Les membres de M12 sont donc seulement method2.

La superclasse directe de B est M12 et est dans le même paquet. Il hérite donc de son membre, method2. B ne sait rien sur method1. Si vous aviez compilé votre code avec javac, vous auriez reçu une erreur de compilation cannot find symbol à la place. (Il semble qu'Eclipse essaie de deviner ce que vous essayez de faire.)

De même, la superclasse directe de A est M12, mais est dans un package différent. Il n'hérite pas method2 pour cette raison. A ne sait rien sur method1 ou method2 car il n'en a pas hérité. Les deux sont des symboles qui ne peuvent pas être trouvés.

Answer 2

La visibilité doit circuler dans la hiérarchie des classes.

La hiérarchie des classes est A --> M12 --> M1

Le depuis M1.method1 n'est pas visible à M12, ce n'est pas visible à toutes les sous-classes de celui-ci soit, comme A.

Answer 3

Je pense que la meilleure façon de comprendre ce comportement est l'idée de « A est un M12 »

Lorsque vous déclarez l'héritage, vous dit A pour obtenir son comportement de M12, mais M12 n'a pas de méthode visible appelée méthode1.

Faisons une expérience pour le plaisir:

public class M12 extends p1.M1 { 
    public void method1() { 
     System.out.println("Method 1 called"); 
    } 
    void method2() { 
     System.out.println("Method 2 called"); 
    } 
} 

A .. Oublier lorsque vous déclarez cette méthode, il est permis - si vous ne disposez pas d'un @Override sur elle. cependant, si M1 était:

public class M1 { 
    public void method1() { 
     System.out.println("Method 1 called"); 
    } 
} 

vous pourriez avoir:

public class M12 extends p1.M1 { 
    @Override 
    public void method1() { 
     System.out.println("Method 1 called"); 
    } 

    void method2() { 
     System.out.println("Method 2 called"); 
    } 
} 

maintenant, retour au code original pour M1 et M2 avec la méthode nouvelle déclarée et méthode un rendu public:

public class M12 extends p1.M1 { 
    public void method1() { 
     System.out.println("Method 1 called"); 
    } 

    public void method2() { 
     System.out.println("Method 2 called"); 
    } 
} 

Ensuite, vous seriez en mesure d'avoir

public class A extends M12 { 

    public void doSomething() { 
     method1(); 
     method2(); 
    } 
} 

ok, c'est un cas trivial, mais serait manquant pour compléter le séquençage ... ligne de fond, sémantiquement, vous pourriez expliquer par la relation IS.

---

Si plus est nécessaire (https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html):

Le tableau suivant montre l'accès aux membres autorisés par chaque modification.

Niveaux d'accès

Modifier Class Package Subclass World 

public  Y  Y  Y   Y 

protected Y  Y  Y   N 

no modifier Y  Y  N   N 

private  Y  N  N   N