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

(avertissement: Je ne suis pas un programmeur Java, je suis un programmeur Perl. Perl n'a pas de protections formelles ce qui explique peut-être pourquoi je comprends si bien le problème:))

privé

comme vous le pensez, seule la classe dans laquelle il est déclaré peut le voir.

Colis 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 considèrent comme une erreur).

protégé

paquet privé + peut être vu par des sous-classes ou un membre du paquet.

Public

tout le monde peut le voir.

publié

Visible hors du contrôle du code I. (Bien que ce ne soit pas la syntaxe Java, c'est important pour cette discussion).

c++ définit un niveau supplémentaire appelé "ami" et le moins vous connaissez le mieux.

quand utiliser quoi? L'idée est d'encapsuler pour cacher l'information. Autant que possible, vous voulez cacher le détail de la façon dont quelque chose est fait de vos utilisateurs. Pourquoi? Parce que vous pourrez les changer plus tard et ne briser le code de personne. Cela vous permet d'optimiser, de remanier, de redessiner et de corriger les bogues sans crainte que quelqu'un utilise ce code que vous venez de réviser.

ainsi, la règle de base est de rendre les choses aussi visibles qu'elles doivent l'être. Commencez par privé et ajoutez seulement plus de visibilité si nécessaire. Seulement rendre public ce qui est absolument nécessaire pour l'utilisateur de savoir, chaque détail que vous faites public crampes votre capacité à redessiner le système.

si vous voulez que les utilisateurs soient en mesure de personnaliser les comportements, plutôt que de rendre les internes publics afin qu'ils puissent les outrepasser, il est souvent une meilleure idée de pousser ces tripes dans un objet et rendez cette interface publique. De cette façon, ils peuvent tout simplement brancher un nouvel objet. Par exemple, si vous étiez en train d'écrire un lecteur de CD et que vous vouliez le "go find info about this CD" bit customizable, plutôt que de rendre ces méthodes publiques, vous mettriez toutes ces fonctionnalités dans son propre objet et rendriez juste votre objet getter/setter public. De cette façon, être avare d'exposer ses tripes encourage une bonne composition et la séparation des préoccupations

personnellement, je reste avec juste " privé" et "public". Beaucoup de langues OO ont juste cela. "Protégé" peut être pratique, mais c'est vraiment un tricheur. 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 d'autres personnes pour trouver des utilisations.

C'est là que l'idée de "publié". Changer une interface (le refactoriser) exige que vous trouviez tout le code qui l'utilise et que vous le changiez aussi. Si l'interface est privée, bien aucun problème. Si elle est protégée, vous aller trouver tous les sous-classes. Si elle est publique, vous devez aller trouver tout le code qui utilise votre code. Parfois, c'est possible, par exemple si vous travaillez sur un code d'entreprise qui n'est destiné qu'à un usage interne, peu importe qu'une interface soit publique. Vous pouvez récupérer tout le code du dépôt corporatif. Mais si une interface est "publiée", s'il y a du code qui l'utilise hors de votre contrôle, alors vous êtes fichu. Vous devez supporter cette interface ou le code de risque de rupture. Même protégé les interfaces peuvent être considérées comme publiées (c'est pourquoi je ne prends pas la peine de les protéger).

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

Voici une meilleure version de la table. (L'avenir avec une colonne pour les modules.)

explications

• Un privé membre seulement accessible à l'intérieur de la même classe qu'elle est déclarée.

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

• a protégé membre accessible dans toutes les classes du même colis et dans les sous-classes des autres colis.

• Un public membre est accessible à toutes les classes (à moins qu'elle ne réside dans un module qui n'exporte pas le colis dans lequel elle est déclarée).

quel modificateur choisir?

modificateurs D'accès est un outil pour vous aider à prévenir accidentellement briser encapsulation ^(*) . Demandez-vous si vous voulez que le membre soit quelque chose qui est interne à la classe, paquet, classe hiérarchie ou pas du tout interne, et choisir 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 de mise en œuvre.
• une classe qui ne devrait être instanciée que dans une classe d'usine (dans le même paquet) devrait avoir un constructeur de paquets restreint, car il ne devrait pas être possible de l'appeler directement de l'extérieur paquet.
• une méthode interne appelée void beforeRender() juste avant le rendu et utilisée comme un crochet dans les sous-classes devrait être protégée.
• a void saveGame(File dst) méthode qui est appelé à partir du code GUI devrait être publique.

^{(*) Qu'est-ce que L'Encapsulation?}

                | 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. Début de déclarer tout privé. Puis, au fur et à mesure que les besoins se font sentir, on progresse vers le public et la conception le justifie.

lorsque vous exposez des membres, demandez-vous si vous exposez des choix de représentation ou 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 primordial implémentations de méthode par sous-classification; il est trop facile de foirer la logique. Déclarez les méthodes protégées abstraites si vous avez l'intention de les annuler.

de plus, utilisez l'annotation @Override lors de la suppression pour éviter que les choses ne se cassent lors du remaniement.

c'est en fait un peu plus compliqué qu'une simple grille montre. La grille vous dit si un accès est autorisé, mais qu'est-ce qui constitue exactement un accès? De plus, les niveaux d'accès interagissent de façon complexe avec les classes imbriquées et l'héritage.

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

résumé

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

• membre est private : seulement si le membre est défini dans la même classe que le code d'appel.
• Membre est colis privé: Seulement si le code d'appel est à l'intérieur du membre immédiatement en joignant paquet.
• membre est protected : même paquet, ou si le membre est défini dans une superclasse de la classe contenant le code d'appel.
• Membre public : Oui.

Ce spécificateurs d'accès s'appliquent à

les variables Locales et les paramètres formels ne peuvent pas prendre des spécificateurs d'accès. Étant donné qu'elles sont essentiellement inaccessibles à l'extérieur selon les règles de détermination de la portée, elles sont effectivement privées.

pour les classes le Top scope, seulement 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 colis (il n'y a pas d'héritage des colis).

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

Related: Classe Java Accessibilité

Ordonnance 1519200920"

les spécificateurs d'accès peuvent être commandés strictement

"1519110920 public" > protected > package-privé > privé

signifie que public fournit le plus d'accès, private le moins. Toute référence possible à un membre privé est également valable pour un colis-privé; toute référence à un colis-privé membre est valide sur un membre protégé, et ainsi de suite. (Donnant accès protégé les membres d'autres classes du même paquet ont été considérés comme une erreur.)

Notes

• d'Une classe de méthodes sont autorisés à 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 les objets de n'importe quelle sous-classe de C. Java ne supporte pas la restriction d'accès par instance, seulement par classe. (Comparer avec Scala, qui fait support à l'aide de private[this] .)
• Vous avez besoin d'accéder à un constructeur pour construire un objet. Ainsi, si tous les constructeurs sont privés, la classe ne peut être construite que par un code vivant dans la classe (généralement des méthodes statiques d'usine ou des initialisateurs statiques de variables). Il en va de même pour le package-Private ou protected constructors.
  • le fait de N'avoir que des constructeurs privés signifie également que la classe ne peut pas être sous-classée à l'extérieur, étant donné que Java exige une les constructeurs de la sous-classe appellent implicitement ou explicitement un constructeur de superclasses. (Elle peut cependant contenir une classe imbriquée qui la sous-classe.)

classes intérieures

vous devez également considérer emboîtés scopes, tels que les classes intérieures. Un exemple de la complexité est que les classes intérieures ont des membres, qui peuvent eux-mêmes prendre des modificateurs d'accès. Pour que tu puisses avoir une classe privée avec un membre public; le membre peut-il être consulté? (Voir ci-dessous.) La règle générale est d'examiner la portée et de réfléchir de façon récursive pour voir si vous pouvez accéder à chaque niveau.

Cependant, c'est assez compliqué, et pour plus de détails, consulter la Java Language Specification . (Oui, il y a eu des bogues de compilateur dans le passé.)

pour un avant-goût de la façon dont ceux-ci interagissent, considérez cet exemple. Il est possible de "fuir" l'intérieur privé classes; il s'agit habituellement d'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

Certaines questions connexes:

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

en règle générale:

• privé : étendue de classe.
• par défaut (ou colis-privé ): l'étendue d'un package.
• protégé : package scope + child (comme package, mais nous pouvons le sous-classe de différents packages). 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 d'une méthode à l'intérieur de la même classe).
• (R)eference (appeler une méthode à l'aide d'une référence à la classe, ou de la "dot" de la syntaxe).
• (I)nheritance (via sous-classement).

alors nous avons cette table 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 court

• public : accessible de partout.
• protected : accessible par les classes du même colis et les sous-classes qui y résident.
• par défaut (aucun modificateur spécifié): accessible par les classes du même paquet.
• private : accessible dans la même classe seulement.

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

• supposons que nous ayons deux classes; Father et Son , chacune dans son propre colis:

  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 dans 4 contextes:

  1. à l'intérieur D'une classe qui est située dans le même colis où foo() est défini ( fatherpackage ):

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

  2. à l'intérieur d'une sous-classe, sur l'instance actuelle 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 mère et qui est à l'intérieur de le colis dans lequel foo() est défini ( fatherpackage ) [ceci 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 mère et c'est à l'extérieur 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 éléments protégés de son parent, et elle 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 qui sont déclarés privés ne peuvent être accessibles qu'à l'intérieur de la classe déclarée elle-même.

• Classe et d'Interface

le modificateur D'accès privé est le niveau d'accès le plus restrictif. Classe et les interfaces ne peuvent pas être privé.

Note

les Variables qui sont déclarées privées peuvent être consultées en dehors de la classe si les méthodes getter publiques sont présentes dans la classe. Les Variables, les méthodes et les constructeurs qui sont déclarés protégés dans une superclasse ne peuvent être accessibles que par les sous-classes d'un autre paquet ou d'une classe quelconque dans le paquet de la classe des membres protégés.

protégé

• Classe et d'Interface

le modificateur d'accès protégé ne peut être appliqué à la classe et aux interfaces.

, 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. déclarée protégée.

Note

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

Public

une classe, méthode, constructeur, interface etc déclaré public peut être consulté à partir de toute autre classe.

par conséquent, les champs, méthodes, blocs déclarés à l'intérieur d'une classe publique peuvent être consultés à partir de n'importe quelle classe appartenant à L'univers Java.

• Colis Différents

cependant si la classe publique nous essayons d'accéder est dans un paquet différent, alors la classe publique doit encore être importé.

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

par Défaut -Pas de mot-clé:

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

• dans les mêmes colis

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

Note

nous ne pouvons pas outrepasser les champs statiques.si vous essayez d'annuler il ne montre aucune erreur mais elle n'est pas ce que nous sauf.

Réponses

• méthodes statiques prépondérantes 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 peut être trouvée dans les liens déjà fournis mais celui à utiliser se résume généralement au"principe de la moindre connaissance". Autoriser uniquement les moins de visibilité de ce qui est nécessaire.

privé : accès limité à la classe seulement

par Défaut (pas de modificateur) : l'accès Limité à la classe et le paquet

protégé : accès limité à la classe, au colis et aux sous-classes (colis intérieur et extérieur)

Public : Accessible à la classe, au (X) colis (s) et aux sous-classes... En bref, partout.

modificateurs D'accès en Java.

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

1. Par défaut:

Accessible uniquement aux classes du même colis.

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 l'accès public et protégé, mais moins restreint que l'accès privé.

2. Public

est accessible de n'importe où. (Global Access)

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: Hello

3. Privé

Accessible uniquement dans la même classe.

si vous essayez d'accéder à des membres privés sur une classe dans une autre va jeter l'erreur de compilation. Pour 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 colis 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: Hello

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

Public: il 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 la même colis de n'importe quelle classe de colis.

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

protégé: vous pouvez accéder aux variables dans le même paquet ainsi qu'à la sous-classe dans tout autre paquet. donc, fondamentalement, il 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 accès dans la même classe.

dans les méthodes non statiques vous pouvez accéder directement à cause de cette" référence 151940920 " (aussi dans les constructeurs)mais pour accéder dans les méthodes statiques vous devez créer objet de la classe.