Quelle est la différence entre public, protected, package-private et private en Java?

(Mise en garde: Je ne suis pas un programmeur Java, je suis un programmeur Perl. Perl n'a pas de protections formelles, c'est peut-être pourquoi je comprends si bien le problème:))

Privé

Comme vous le pensez, seule la classe dans laquelle elle est déclarée peut le voir.

Paquet privé

Ne peut être vu et utilisé que par le paquet dans lequel il a été déclaré. C'est la valeur par défaut en Java (que certains voient comme une erreur).

Protégé

Paquet privé + peut être vu par les sous-classes ou les membres du package.

Public

Tout le monde peut le voir.

Publié

Visible en dehors du code que je contrôle. (Bien que ce ne soit pas la syntaxe Java, elle est importante pour cette discussion).

C++ définit un niveau supplémentaire appelé "ami" et moins vous en savez, mieux c'est.

Quand devriez-vous utiliser quoi? L'idée est l'encapsulation pour cacher des informations. Autant que possible vous voulez cacher le détail de la façon dont quelque chose est fait à partir de vos utilisateurs. Pourquoi? Parce qu'alors vous pouvez les changer plus tard et ne casser le code de personne. Cela vous permet d'optimiser, de refactoriser, de redessiner et de corriger les bogues sans vous soucier que quelqu'un utilise ce code que vous venez de réviser.

Donc, la règle de base est de rendre les choses aussi visibles qu'elles doivent l'être. Commencez avec privé et ajoutez seulement plus de visibilité au besoin. Ne rendre public que ce qui est absolument nécessaire pour que l'utilisateur sache, chaque détail que vous rendez public entrave votre capacité à redessiner le système.

Si vous voulez que les utilisateurs puissent personnaliser les comportements, plutôt que de rendre les internes publics afin qu'ils puissent les remplacer, il est souvent préférable de pousser ces tripes dans un objet et de rendre cette interface publique. De cette façon, ils peuvent simplement brancher un nouvel objet. Par exemple, si vous écriviez un lecteur de CD et que vous vouliez personnaliser le bit "go find info about this CD", plutôt que de rendre ces méthodes publiques, vous mettriez toutes ces fonctionnalités dans son propre objet et faites juste votre objet getter/setter public. De cette façon, être avare d'exposer vos tripes encourage une bonne composition et la séparation des préoccupations

Personnellement, je m'en tiens à juste "privé "et"public". Beaucoup de langues OO ont juste cela. "Protégé" peut être pratique, mais c'est vraiment une triche. Une fois qu'une interface est plus que privée, elle est hors de votre contrôle et vous devez aller chercher dans le code des autres pour trouver des utilisations.

C'est là que l'idée de "publié" entre en jeu. Changer une interface (la refactoriser) nécessite que vous trouviez tout le code qui l'utilise et que vous le changiez également. Si l'interface est privée, eh bien pas de problème. S'il est protégé, vous devez aller trouver toutes vos sous-classes. Si elle est publique, vous devez aller trouver tout le code qui utilise votre code. Parfois, cela est possible, par exemple si vous travaillez sur du code d'entreprise à usage interne uniquement, peu importe qu'une interface soit publique. Vous pouvez extraire tout le code du référentiel d'entreprise. Mais si une interface est "publiée", s'il y a du code qui l'utilise en dehors de votre contrôle, alors vous êtes arrosé. Vous devez prendre en charge cette interface ou risquer de casser le code. Même les interfaces protégées peuvent être considérées comme publiées (c'est pourquoi je ne me soucie pas de protected).

De nombreuses langues trouvent que la nature hiérarchique du public/protégé/privé est trop limitative et non conforme à la réalité. À cette fin, il y a le concept d'une classe de traits , mais c'est un autre spectacle.

Voici une meilleure version du tableau. (Preuve future avec une colonne pour les modules.)

Explications

• Un membre privé est uniquement accessible dans la même classe qu'il est déclaré.

• Un membre avec aucun modificateur d'accès n'est accessible que dans les classes du même package.

• Un protégé membre est accessible dans toutes les classes dans le même paquet et dans les sous-classes d'autres paquets.

• Un membre public est accessible à toutes les classes (sauf s'il réside dans un module qui n'exporte pas le paquet dans lequel il est déclaré).

Quel modificateur choisir?

Access modificateurs est un outil pour vous aider à prévenir accidentellement rupture encapsulation^(*). Demandez - vous si vous avez l'intention que le membre soit quelque chose qui est interne à la classe, paquet, hiérarchie de classe ou pas interne du tout, et choisissez le niveau d'accès en conséquence.

Exemples:

• Un champ long internalCounter devrait probablement être privé car il est mutable et un détail d'implémentation.
• Une classe qui ne devrait être instanciée que dans une classe d'usine (dans le même paquet) devrait avoir un constructeur limité au paquet, car il ne devrait pas être possible de l'appeler directement depuis l'extérieur du paquet.
• Une méthode interne void beforeRender() appelée juste avant le rendu et utilisé comme un crochet dans les sous-classes doit être protégé.
• Une méthode void saveGame(File dst) appelée à partir du code GUI doit être publique.

^{(*) Qu'est-ce que l'encapsulation exactement?}

                | highest precedence <---------> lowest precedence
*———————————————+———————————————+———————————+———————————————+———————
 \ xCanBeSeenBy | this          | any class | this subclass | any
  \__________   | class         | in same   | in another    | class
             \  | nonsubbed     | package   | package       |    
Modifier of x \ |               |           |               |       
————————————————*———————————————+———————————+———————————————+———————
public          |       ✔       |     ✔     |       ✔       |   ✔   
————————————————+———————————————+———————————+———————————————+———————
protected       |       ✔       |     ✔     |       ✔       |   ✘   
————————————————+———————————————+———————————+———————————————+———————
package-private |               |           |               |
(no modifier)   |       ✔       |     ✔     |       ✘       |   ✘   
————————————————+———————————————+———————————+———————————————+———————
private         |       ✔       |     ✘     |       ✘       |   ✘    

Règle facile. Commencez par déclarer tout privé. Et puis progresser vers le public au fur et à mesure que les besoins se présentent et que la conception le justifie.

Lorsque vous exposez des membres, demandez-vous si vous exposez des choix de représentation ou des choix d'abstraction. Le premier est quelque chose que vous voulez éviter car il introduira trop de dépendances sur la représentation réelle plutôt que sur son comportement observable.

En règle générale, j'essaie d'éviter de remplacer les implémentations de méthode en sous-classant; c'est trop facile de bousiller la logique. Déclarez les méthodes protégées abstraites si vous avez l'intention de les remplacer.

Utilisez également l'annotation @Override lors du remplacement pour empêcher les choses de se casser lorsque vous refactorisez.

C'est en fait un peu plus compliqué qu'une simple grille ne le montre. La grille vous indique si un accès est autorisé, mais qu'est-ce qui constitue exactement un accès? En outre, les niveaux d'accès interagissent avec les classes imbriquées et l'héritage de manière complexe.

L'accès "par défaut" (spécifié par l'absence d'un mot clé) est aussi appelé colis-privé. Exception: dans une interface, aucun modificateur ne signifie accès public; les modificateurs autres que public sont interdits. Les constantes Enum sont toujours public.

Résumé

Est un accès à un membre avec ce spécificateur d'accès autorisé?

• Member est private: Uniquement si member est défini dans la même classe que le code appelant.
• Le membre est privé du package: uniquement si le code appelant se trouve dans le package immédiatement englobant du membre.
• Member est protected: Même package, ou si member est défini dans une superclasse de la classe contenant le code appelant.
• Le membre est public: Oui.

À quoi s'appliquent les spécificateurs d'accès

Les variables locales et les paramètres formels ne peuvent pas prendre les spécificateurs d'accès. Comme ils sont intrinsèquement inaccessibles à l'extérieur selon les règles de cadrage, ils sont effectivement privés.

Pour les classes de la portée supérieure, seuls public et package-private sont autorisés. Ce choix de conception est probablement dû au fait que protected et private seraient redondants au niveau du paquet (il n'y a pas d'héritage de paquets).

Tous les les spécificateurs d'accès sont possibles sur les membres de classe (constructeurs, méthodes et fonctions membres statiques, classes imbriquées).

Lié: Accessibilité de classe Java

Commande

Les spécificateurs d'accès peuvent être strictement ordonné

Public > protégé > paquet-privé > privé

Ce qui signifie que public fournit le plus d'accès, private le moins. Toute référence possible sur un membre privé est également valable pour un forfait-membre privé; tout référence à un forfait-membre privé est valable sur un membre protégé, et ainsi de suite. (Donner accès aux membres protégés à d'autres classes dans le même paquet était considéré comme une erreur.)

Notes

• Les méthodes d'une classe sont autorisées à accéder aux membres privés d'autres objets de la même classe. Plus précisément, une méthode de classe C peut accéder aux membres privés de C sur des objets de n'importe quelle sous-classe de C. Java ne prend pas en charge la restriction d'accès par instance, uniquement par classe. (Comparez avec Scala, qui le prend en charge en utilisant private[this].)
• Vous devez accéder à un constructeur pour construire un objet. Ainsi, si tous les constructeurs sont privés, la classe ne peut être construite que par du code vivant dans la classe (généralement des méthodes d'usine statiques ou des initialiseurs de variables statiques). De même pour les constructeurs privés ou protégés.
  • N'avoir que des constructeurs privés signifie également que la classe ne peut pas être sous-classée en externe, car Java nécessite un les constructeurs de sous-classe pour appeler implicitement ou explicitement un constructeur de superclasse. (Il peut cependant contenir une classe imbriquée qui la sous-classe.)

Classes internes

Vous devez également considérer les étendues imbriquées, telles que les classes internes. Un exemple de la complexité est que les classes internes ont des membres, qui peuvent eux-mêmes prendre des modificateurs d'accès. Vous pouvez donc avoir une classe interne privée avec un membre public; le membre peut-il être consulté? (Voir ci-dessous.) Le la règle générale est de regarder la portée et de penser récursivement pour voir si vous pouvez accéder à chaque niveau.

Cependant, cela est assez compliqué, et pour plus de détails, consultez la spécification du langage Java. (Oui, il y a eu des bugs de compilateur dans le passé.)

Pour un avant-goût de la façon dont ceux-ci interagissent, considérons cet exemple. Il est possible de "fuir" des classes internes privées; c'est généralement un avertissement:

class Test {
    public static void main(final String ... args) {
        System.out.println(Example.leakPrivateClass()); // OK
        Example.leakPrivateClass().secretMethod(); // error
    }
}

class Example {
    private static class NestedClass {
        public void secretMethod() {
            System.out.println("Hello");
        }
    }
    public static NestedClass leakPrivateClass() {
        return new NestedClass();
    }
}

Sortie du Compilateur:

Test.java:4: secretMethod() in Example.NestedClass is defined in an inaccessible class or interface
        Example.leakPrivateClass().secretMethod(); // error
                                  ^
1 error

Certains liés questions:

• Java - Méthode d'accessibilité à l'intérieur des colis-privé de classe?

En règle générale:

• private : portée de la classe.
• default (ou colis-privé): l'étendue d'un package.
• protected : portée du paquet + enfant (comme le paquet, mais nous pouvons le sous-classer à partir de différents paquets). Le modificateur protégé conserve toujours la relation "parent-enfant".
• public: partout.

En conséquence, si nous divisons le droit d'accès en trois droits:

• (D)irect (invoquer à partir d'une méthode dans la même classe).
• (R)eference (invoquer une méthode en utilisant une référence à la classe, ou via la syntaxe "dot").
• (I)nheritance (par l'intermédiaire de sous-classement).

Alors nous avons ce tableau simple:

+—-———————————————+————————————+———————————+
|                 |    Same    | Different |
|                 |   Package  | Packages  |
+—————————————————+————————————+———————————+
| private         |   D        |           |
+—————————————————+————————————+———————————+
| package-private |            |           |
| (no modifier)   |   D R I    |           |
+—————————————————+————————————+———————————+
| protected       |   D R I    |       I   |
+—————————————————+————————————+———————————+
| public          |   D R I    |    R  I   |
+—————————————————+————————————+———————————+

En très bref

• public: accessible de partout.
• protected: accessible par les classes du même paquet et les sous-classes résidant dans n'importe quel paquet.
• default (aucun modificateur spécifié): accessible par les classes du même paquet.
• private: accessible uniquement dans la même classe.

Le modificateur d'accès le plus mal compris en Java est protected. Nous savons qu'il est similaire au modificateur par défaut à une exception près dans laquelle les sous-classes peuvent le voir. Mais comment? Voici un exemple qui, espérons-le, clarifie la confusion:

• Supposons que nous avons 2 classes; Father et Son, chacune dans son propre paquet:

  package fatherpackage;
  
  public class Father
  {
  
  }
  
  -------------------------------------------
  
  package sonpackage;
  
  public class Son extends Father
  {
  
  }
  

• Ajoutons une méthode protégée foo() à Father.

  package fatherpackage;
  
  public class Father
  {
      protected void foo(){}
  }
  

• La méthode foo() peut être appelée en 4 contextes:

  1. Dans une classe qui se trouve dans le même paquet où foo() est défini (fatherpackage):

     package fatherpackage;
     
     public class SomeClass
     {
         public void someMethod(Father f, Son s)
         {
             f.foo();
             s.foo();
         }
     }
     

  2. Dans une sous-classe, sur l'instance en cours via this ou super:

     package sonpackage;
     
     public class Son extends Father
     {
         public void sonMethod()
         {
             this.foo();
             super.foo();
         }
     }
     

  3. Sur une référence dont le type est la même classe:

     package fatherpackage;
     
     public class Father
     {
         public void fatherMethod(Father f)
         {
             f.foo(); // valid even if foo() is private
         }
     }
     
     -------------------------------------------
     
     package sonpackage;
     
     public class Son extends Father
     {
         public void sonMethod(Son s)
         {
             s.foo();
         }
     }
     

  4. Sur une référence dont le type est la classe parente et c'est dans le paquet où foo() est défini (fatherpackage) [Cela peut être inclus dans le contexte no. 1]:

     package fatherpackage;
     
     public class Son extends Father
     {
         public void sonMethod(Father f)
         {
             f.foo();
         }
     }
     

• Les situations suivantes ne sont pas valides.

  1. Sur une référence dont le type est la classe parente et c'est en dehors de le paquet où foo() est défini (fatherpackage):

     package sonpackage;
     
     public class Son extends Father
     {
         public void sonMethod(Father f)
         {
             f.foo(); // compilation error
         }
     }
     

  2. Une non-sous-classe à l'intérieur d'un paquet d'une sous-classe (Une sous-classe hérite des membres protégés de son parent et les rend privés aux non-sous-classes):

     package sonpackage;
     
     public class SomeClass
     {
         public void someMethod(Son s) throws Exception
         {
             s.foo(); // compilation error
         }
     }
     

Privé

• Méthodes, Variables et constructeurs

Les méthodes, Variables et constructeurs déclarés privés ne sont accessibles que dans la classe déclarée elle-même.

• Classe et interface

modificateur d'accès Privé est le plus restrictif niveau d'accès. La classe et les interfaces ne peuvent pas être privées.

Remarque

Les variables déclarées privées sont accessibles en dehors de la classe si des méthodes getter publiques sont présentes dans la classe. Les variables, méthodes et constructeurs déclarés protégés dans une superclasse ne sont accessibles que par les sous-classes d'un autre package ou par toute classe du package de la classe des membres protégés.

Protégé

• Classe et interface

Le modificateur d'accès protégé ne peut pas être appliqué à la classe et interface.

Les méthodes et les champs peuvent être déclarés protégés, mais les méthodes et les champs d'une interface ne peuvent pas être déclarés protégés.

Remarque

L'accès protégé donne à la sous-classe la possibilité d'utiliser la méthode ou la variable d'assistance, tout en empêchant une classe non liée d'essayer de l'utiliser.

Public

Une classe, une méthode, un constructeur, une interface, etc. déclarés publics peuvent être accessible à partir de toute autre classe.

Par conséquent, les champs, méthodes, blocs déclarés dans une classe publique sont accessibles à partir de n'importe quelle classe appartenant à l'univers Java.

• Différents Forfaits

Cependant, si la classe publique à laquelle nous essayons d'accéder se trouve dans un package différent, la classe publique doit toujours être importée.

En raison de l'héritage de classe, toutes les méthodes et variables publiques d'une classe sont hérité par ses sous-classes.

Par défaut - Aucun mot-clé:

Le modificateur d'accès par défaut signifie que nous ne déclarons pas explicitement un modificateur d'accès pour une classe, un champ, une méthode, etc.

• Dans les mêmes paquets

Une variable ou une méthode déclarée sans aucun modificateur de contrôle d'accès est disponible pour toute autre classe du même package. Les champs d'une interface sont implicitement public static final et les méthodes dans une interface sont par défaut publiques.

Remarque

Nous ne pouvons pas remplacer les champs statiques.si vous essayez de remplacer il ne montre aucune erreur mais il ne fonctionne pas ce que nous sauf.

Réponses connexes

• Surchargeant les méthodes statiques en java

Références liens

Http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html http://www.tutorialspoint.com/java/java_access_modifiers.htm

La différence se trouve dans les liens déjà fournis mais celui à utiliser se résume généralement au "Principe de la moindre Connaissance". N'autorisez que le moins de visibilité nécessaire.

Privé : Accès limité à la classe seulement

Par défaut (pas de modificateur): Accès limité à la classe et au package

Protected : Accès limité à la classe, au package et aux sous-classes (à la fois à l'intérieur et à l'extérieur du package)

Public : Accessible à la classe, au package (tous) et aux sous-classes... En bref, partout.

Modificateurs d'Accès en Java.

Les modificateurs d'accès Java sont utilisés pour fournir un contrôle d'accès en Java.

1. Par défaut:

Accessible uniquement aux classes du même package.

Par exemple

// Saved in file A.java
package pack;

class A{
  void msg(){System.out.println("Hello");}
}

// Saved in file B.java
package mypack;
import pack.*;

class B{
  public static void main(String args[]){
   A obj = new A(); // Compile Time Error
   obj.msg(); // Compile Time Error
  }
}

Cet accès est plus restreint que public et protégé, mais moins restreint que privé.

2. Public

Est accessible de n'importe où. (Accès mondial)

Par exemple

// Saved in file A.java

package pack;
public class A{
  public void msg(){System.out.println("Hello");}
}

// Saved in file B.java

package mypack;
import pack.*;

class B{
  public static void main(String args[]){
    A obj = new A();
    obj.msg();
  }
}

Sortie: Bonjour

3. Privé

Accessible uniquement à l'intérieur de la même classe.

Si vous essayez d'accéder à des membres privés sur une classe dans une autre, une erreur de compilation sera générée. Par exemple,

class A{
  private int data = 40;
  private void msg(){System.out.println("Hello java");}
}

public class Simple{
  public static void main(String args[]){
    A obj = new A();
    System.out.println(obj.data); // Compile Time Error
    obj.msg(); // Compile Time Error
  }
}

4. Protégé

Accessible uniquement aux classes du même package et aux sous-classes

Par exemple

// Saved in file A.java
package pack;
public class A{
  protected void msg(){System.out.println("Hello");}
}

// Saved in file B.java
package mypack;
import pack.*;

class B extends A{
  public static void main(String args[]){
    B obj = new B();
    obj.msg();
  }
}

Sortie: Bonjour

Modificateurs d'Accès sont là pour restreindre l'accès à plusieurs niveaux.

Public: C'est fondamentalement aussi simple que vous pouvez accéder à partir de n'importe quelle classe, que ce soit dans le même paquet ou non.

Pour l'accès si vous êtes dans le même package, vous pouvez accéder directement, mais si vous êtes dans un autre paquet, vous pouvez créer un objet de la classe.

Par défaut: Il est accessible dans le même paquet depuis n'importe quelle classe de paquet.

Pour y accéder, vous pouvez créer un objet de la classe. Mais vous ne pouvez pas accéder à cette variable en dehors du package.

Protected: vous pouvez accéder à des variables dans le même paquet ainsi qu'à une sous-classe dans n'importe quel autre paquet. donc, fondamentalement, c'est par défaut + Hérité comportement.

Pour accéder au champ protégé défini dans la classe de base, vous pouvez créer un objet de la classe enfant.

Privé:, il peut être l'accès dans la même classe.

Non-méthodes statiques, vous pouvez accéder directement à cause de ce référence (également dans les constructeurs)mais pour accéder aux méthodes statiques, vous devez créer un objet de la classe.

Visible sur le paquet. Défaut. Pas de modificateurs sont nécessaires.

Visibles à la seule classe (private).

Visible au monde (public ).

Visible pour le paquet et toutes les sous-classes (protégé ).

Les variables et les méthodes peuvent être déclarées sans aucun modificateur appelé. Exemples par défaut:

String name = "john";

public int age(){
    return age;
}

Modificateur d'accès Privé - privé:

Les méthodes, variables et constructeurs déclarés privés ne peuvent être accessible dans la classe déclarée elle-même. Le modificateur d'accès privé est le plus restrictif niveau d'accès. La classe et les interfaces ne peuvent pas être privées.

Les variables déclarées privées sont accessibles en dehors de la classe si des méthodes getter publiques sont présentes dans la classe.

L'utilisation du modificateur privé est le principal moyen pour un objet de s'encapsuler et de masquer les données du monde extérieur.

Exemples:

Public class Details{

    private String name;

    public void setName(String n){
        this.name = n;
    }

    public String getName(){
        return this.name;
    }
}

Modificateur d'accès public-public:

Un classe, méthode, constructeur, interface, etc. public déclaré est accessible depuis n'importe quelle autre classe. Par conséquent, les champs, méthodes, blocs déclarés dans une classe publique sont accessibles à partir de n'importe quelle classe appartenant à l'univers Java.

Cependant, si la classe publique à laquelle nous essayons d'accéder est dans un paquet différent, la classe publique doit toujours être importée.

En raison de l'héritage de classe, toutes les méthodes et variables publiques d'une classe sont héritées par son les sous-classes.

Exemple:

public void cal(){

}

Modificateur d'accès protégé-protégé:

Les variables, méthodes et constructeurs déclarés protégés dans une superclasse ne sont accessibles que par les sous-classes d'un autre paquet ou par toute classe du paquet de la classe des membres protégés.

Le modificateur d'accès protégé ne peut pas être appliqué à la classe et aux interfaces. Les méthodes et les champs peuvent être déclarés protégés, mais les méthodes et les champs d'une interface ne peuvent pas être déclarés protégé.

L'accès protégé donne à la sous-classe une chance d'utiliser la méthode ou la variable d'assistance, tout en empêchant une classe non liée d'essayer de l'utiliser.

class Van{

    protected boolean speed(){

    }
}

class Car{
    boolean speed(){
    }

}

• Public - accessible à partir de n'importe où dans l'application.

• Par Défaut - accessible à partir de package.

• Protected - accessible depuis le package et les sous-classes d'un autre package. aussi bien

• Privé - accessible depuis sa classe uniquement.

Je veux juste aborder un détail qui est extrêmement souvent mal obtenu, y compris par la plupart des réponses sur cette page. "par Défaut" accès (quand pas de modificateur d'accès) n'est pas toujours le même que le colis privé-. Cela dépend de ce que la chose est.

• Les types non membres (c'est-à-dire les classes, les énumérations, les interfaces et les types d'annotation non déclarés dans un autre type) sont privés de package par défaut. (JLS §6.6.1)

• Membres du groupe et les constructeurs sont privés par défaut. (JLS §6.6.1)

• Les constructeurs Enum sont privés par défaut . (En effet, les contructeurs enum doivent être privés, et c'est une erreur d'essayer de les rendre publics ou protégés). Les constantes Enum sont publiques et n'autorisent aucun spécificateur d'accès. Les autres membres des énumérations sont privés par défaut. (JLS §8.9)

• Tous les membres des interfaces et types d'annotation sont publics par par défaut. (En effet, les membres des interfaces et types d'annotation doit public, et c'est une erreur d'essayer de les rendre privés ou protégés.) ( JLS §9.3 à 9.5)

Cette page écrit bien sur le modificateur d'accès protégé et par défaut

.... Protected: le modificateur d'accès protégé est un peu délicat et vous pouvez dire qu'il s'agit d'un sur-ensemble du modificateur d'accès par défaut. Les membres protégés sont les mêmes que les membres par défaut en ce qui concerne l'accès dans le même package. La différence est que, les membres protégés sont également accessibles aux sous-classes de la classe dans laquelle le membre est déclaré qui sont en dehors du paquet dans lequel la classe parent est présente.

Mais ces membres protégés ne sont "accessibles en dehors du paquet que par héritage". c'est-à-dire que vous pouvez accéder directement à un membre protégé d'une classe dans sa sous-classe présent dans un autre package comme si le membre était présent dans la sous-classe elle-même. Mais ce membre protégé ne sera pas accessible dans la sous-classe en dehors du package en utilisant la référence de la classe parent. ....

La réponse de David fournit la signification de chaque modificateur d'accès. Quant à savoir quand utiliser chacune, je suggérerais de rendre publiques toutes les classes et les méthodes de chaque classe destinées à un usage externe (son API), et tout le reste privé.

Au fil du temps, vous développerez un sens pour savoir quand rendre certaines classes privées et quand déclarer certaines méthodes protégées pour une utilisation dans les sous-classes.

• Visible sur le paquet. lepar défaut . Pas de modificateurs sont nécessaires.
• Visible uniquement pour la classe; privé .
• Visible au monde; public .
• Visible pour le paquet et toutes les sous-classes; protégé .

Parlons donc du Contrôle d'accès et de l'héritage Les règles suivantes pour les méthodes héritées sont,

• Les méthodes déclarées public dans une superclasse doivent également être publiques dans tous les sous-classes.
• Les méthodes déclarées protected dans une superclasse doivent être protected ou public dans les sous-classes; ils ne peuvent pas être privés.
• Les méthodes déclarées sans contrôle d'accès (aucun modificateur n'a été utilisé) peuvent être déclaré plus privé dans les sous-classes.
• Les méthodes déclarées private ne sont pas héritées du tout, donc il n'y a pas la règle pour eux.

Remarque: C'est juste un supplément pour la accepté de répondre.

Ceci est lié aux modificateurs d'accès Java .

À partir de Modificateurs d'accès Java :

Un modificateur d'accès Java spécifie quelles classes peuvent accéder à une donnée classe et ses champs, constructeurs et méthodes. Les modificateurs d'accès peuvent être spécifié séparément pour une classe, ses constructeurs, ses champs et méthode. Les modificateurs d'accès Java sont également parfois mentionnés dans daily discours en tant que spécificateurs d'accès Java, mais le nom correct est Java access modificateur. Les Classes, les champs, les constructeurs et les méthodes peuvent avoir l'un des quatre modificateurs d'accès Java différents:

• élément de la Liste
• privé
• par défaut (paquet)
• protégé
• public

À partir de Contrôler l'accès aux membres d'une classe tutoriels:

Les modificateurs de niveau d'accès déterminent si d'autres classes peuvent utiliser un champ particulier ou invoquer une méthode particulière. Il y a deux niveaux de contrôle d'accès:

• Au niveau supérieur-public, ou package-private (pas de modificateur explicite).
• Au niveau membre-public, privé, protégé ou package-privé (pas de modificateur explicite).

Une classe peut être déclarée avec le modificateur public, auquel cas la classe est visible à toutes les classes partout. Si une classe n'a pas de modificateur (la valeur par défaut, aussi connu comme colis-privé), il est visible seulement dans son propre paquet

Le tableau suivant montre l'accès aux membres permis par chacun modificateur.

╔═════════════╦═══════╦═════════╦══════════╦═══════╗
║ 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     ║
╚═════════════╩═══════╩═════════╩══════════╩═══════╝

La première colonne de données indique si la classe elle-même a accès à le membre défini par le niveau d'accès. Comme vous pouvez le voir, une classe toujours a accès qu'à ses propres membres. La deuxième colonne indique si classes dans le même package que la classe (indépendamment de leur la filiation) avoir accès à du membre. La troisième colonne indiquer si les sous-classes de la classe déclarée en dehors de ce paquet ont l'accès au membre. La quatrième colonne indique si toutes les classes avoir accès à du membre.

Les niveaux d'accès vous affectent de deux manières. Tout d'abord, lorsque vous utilisez des classes qui proviennent d'une autre source, comme les classes de la plate-forme Java, les niveaux d'accès déterminent quels membres de ces classes sont les vôtres les classes peuvent utiliser. Deuxièmement, lorsque vous écrivez une classe, vous devez décider quel niveau d'accès chaque variable membre et chaque méthode de votre classe devrait avoir.

Public Protected Default et private sont des modificateurs d'accès.

Ils sont destinés à l'encapsulation, ou au masquage et à l'affichage du contenu de la classe.

La classe
1. peut être publique ou par défaut
2. Les membres de la classe peuvent être publics, protégés, par défaut ou privés.

Private n'est pas accessible en dehors de la classe Default est accessible uniquement dans le package. Protégé dans le paquet ainsi que toute classe qui l'étend. Public est ouvert à tous.

Normalement, les variables membres sont définies privées, mais les méthodes membres sont publiques.

Souvent, j'ai réalisé que se souvenir des concepts de base de n'importe quelle langue peut être rendu possible en créant des analogies du monde réel. Voici mon analogie pour comprendre les modificateurs d'accès en Java:

Supposons que vous êtes étudiant dans une université et que vous avez un ami qui vient vous rendre visite le week-end. Supposons qu'il existe une grande statue du fondateur de l'université au milieu du campus.

• Quand vous l'amenez sur le campus, la première chose que vous et votre ami voyez est cette statue. Cela signifie que toute personne qui se promène sur le campus peut regarder la statue sans la permission de l'université. Cela rend la statue commePUBLIQUE .

• Ensuite, vous voulez prendre votre ami à votre dortoir, mais pour cela vous devez vous inscrire en tant que visiteur. Cela signifie qu'il obtient un laissez-passer d'accès (qui est le même que le vôtre) pour entrer dans divers bâtiments du campus. Ce qui rendrait sa carte d'accès comme PROTÉGÉ .

• Votre ami veut se connecter au campus WiFi mais n'a pas les informations d'identification pour le faire. La seule façon qu'il peut obtenir en ligne est si vous partagez votre connexion avec lui. (Rappelez-vous, chaque étudiant qui va à l'université possède également ces identifiants de connexion). Cela rendrait vos informations de connexion comme AUCUN MODIFICATEUR.

• Enfin, votre ami veut lire votre rapport d'étape pour le semestre qui est affiché sur le site. Cependant, chaque étudiant dispose de son propre identifiant personnel pour accéder à cette section du site Web du campus. Cela rendrait ces informations d'identificationPRIVÉES .

J'espère que cela aide!

Lorsque vous envisagez de modificateurs d'accès suffit de penser de cette façon (s'applique à la fois variables et méthodes):

public --> accessible de partout
private --> accessible uniquement dans la même classe où il est déclaré

Maintenant, la confusion se pose quand il s'agit de default et protected

default --> Aucun mot-clé de modificateur d'accès n'est présent. Cela signifie qu'il est disponible strictement dans le package de la classe. Nulle part en dehors de cela paquet il peut être consulté.

protected --> Légèrement moins strict que defaultet en dehors des mêmes classes de package, il est accessible par des sous-classes en dehors du package il est déclaré.

Il s'agit de encapsulation (ou comme l'a déclaré Joe Phillips, la moindre connaissance).

Commencez par le plus restrictif (privé) et voyez si vous avez besoin de modificateurs moins restrictifs plus tard.

Nous utilisons tous des modificateurs de méthode et de membre comme private, public, ... mais une chose que trop peu de développeurs font est d'utiliser des packages pour organiser logiquement le code .

Par exemple: Vous pouvez mettre des méthodes de sécurité sensibles dans un package "sécurité". Ensuite, mettez une classe publique qui accède à une partie du code lié à la sécurité dans ce paquet mais conserve les autres classes de sécurité package privé. Ainsi, les autres développeurs ne pourront utiliser la classe publiquement disponible qu'en dehors de ce paquet (à moins qu'ils ne changent le modificateur). Ce n'est pas une fonctionnalité de sécurité, mais guidera l'utilisation.

Outside world -> Package (SecurityEntryClass ---> Package private classes)

Une autre chose est que les classes qui dépendent beaucoup les unes des autres peuvent se retrouver dans le même paquet et pourraient éventuellement être refactorisées ou fusionnées si la dépendance est trop forte.

Si au contraire vous définissez tout comme public il ne sera pas clair ce qui devrait ou ne devrait pas être accessible, ce qui peut conduire à écrire beaucoup de javadoc (qui n'applique rien via le compilateur...).