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

https://stackoverflow.com/questions/215497

03-07-2019
|

Question

En Java, existe-t-il des règles claires sur le moment d'utilisation de chacun des modificateurs d'accès, à savoir les paramètres par défaut (package private), public , protected et private , en créant class et interface et en traitant de l'héritage?

La solution

Le didacticiel officiel peut vous être utile. .

            │ Class │ Package │ Subclass │ Subclass │ World
            │       │         │(same pkg)│(diff pkg)│ 
────────────┼───────┼─────────┼──────────┼──────────┼────────
public      │   +   │    +    │    +     │     +    │   +     
────────────┼───────┼─────────┼──────────┼──────────┼────────
protected   │   +   │    +    │    +     │     +    │         
────────────┼───────┼─────────┼──────────┼──────────┼────────
no modifier │   +   │    +    │    +     │          │    
────────────┼───────┼─────────┼──────────┼──────────┼────────
private     │   +   │         │          │          │    

 + : accessible         blank : not accessible

Autres conseils

(Avertissement: je ne suis pas un programmeur Java, je suis un programmeur Perl. Perl n’a aucune protection formelle, c’est peut-être pourquoi je comprends si bien le problème :))

Privé

Comme vous pouvez le penser, seule la classe dans laquelle il est déclaré peut le voir.

Paquet privé

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

Protégé

Le paquet Private + peut être vu par les sous-classes ou les membres du paquet.

Public

Tout le monde peut le voir.

publié

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

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

Quand devriez-vous utiliser quoi? L'idée est d'encapsuler pour cacher des informations. Autant que possible, vous souhaitez masquer le détail de la procédure à suivre par vos utilisateurs. Pourquoi? Parce qu'alors vous pouvez les changer plus tard et ne pas casser le code de personne. Cela vous permet d’optimiser, de refactoriser, de repenser et de corriger les bogues sans vous inquiéter du fait que quelqu'un utilisait ce code que vous venez de réviser.

La règle générale est donc de rendre les choses aussi visibles qu’elles doivent être. Commencez avec privé et ajoutez seulement plus de visibilité au besoin. Ne publiez que ce qui est absolument nécessaire pour que l’utilisateur sache, chaque détail rendu public restreint votre capacité à remodeler le système.

Si vous souhaitez que les utilisateurs puissent personnaliser les comportements plutôt que de rendre publics les utilisateurs internes afin de pouvoir les remplacer, il est souvent préférable de placer ces entrailles dans un objet et de rendre cette interface publique. De cette façon, ils peuvent simplement brancher un nouvel objet. Par exemple, si vous étiez en train d’écrire un lecteur de CD et que vous souhaitiez que le message "Va chercher des informations sur ce CD" Un peu personnalisable, plutôt que de rendre ces méthodes publiques, vous mettriez toute cette fonctionnalité dans son propre objet et ne feriez que rendre votre getter / setter public. De cette façon, être avare d’exposer vos tripes encourage une bonne composition et une séparation des préoccupations

Personnellement, je ne m'en tiens qu'à "privé". et "public". Beaucoup de langues OO ont juste ça. " Protected " peut être pratique, mais c'est vraiment une triche. Une fois qu'une interface est plus que privée, vous ne pouvez plus en contrôler le code et vous devez chercher dans le code d'autres personnes pour en trouver les utilisations.

C’est là que l’idée de " publié " La modification d'une interface (sa refactorisation) nécessite que vous trouviez tout le code qui l'utilise et que vous le changiez également. Si l'interface est privée, bon pas de problème. Si c'est protégé, vous devez aller chercher toutes vos sous-classes. Si c'est public, vous devez aller chercher tout le code qui utilise votre code. Cela est parfois possible. Par exemple, si vous travaillez sur un code d'entreprise destiné uniquement à un usage interne, peu importe si une interface est publique. Vous pouvez extraire tout le code du référentiel de l'entreprise. Mais si une interface est "publiée", s'il y a du code l'utilisant en dehors de votre contrôle, alors vous êtes bloqué. Vous devez prendre en charge cette interface ou ce code de rupture de risque. Même les interfaces protégées peuvent être considérées comme publiées (c'est pourquoi je ne me soucie pas de protéger).

Beaucoup de langues trouvent la nature hiérarchique de public / protected / private trop limitative et non conforme à la réalité. À cette fin, il existe le concept d'une classe de traits , mais c'est un autre spectacle.

Voici une meilleure version de la table. (Preuve future avec une colonne pour les modules.)

Explications

Un membre privé ( i ) est uniquement accessible dans la même classe que celle déclarée.
Un membre avec aucun modificateur d'accès ( j ) est uniquement accessible dans les classes du même package.
Un membre protected ( k ) est accessible dans toutes les classes du même package et dans des sous-classes d'autres packages.
Un membre public ( l ) est accessible à toutes les classes (sauf s'il réside dans un module qui n'exporte pas le package dans lequel il est déclaré).

Quel modificateur choisir?

Access modifiers est un outil destiné à vous aider à prévenir la rupture accidentelle de l’encapsulation ^(*). Demandez-vous si vous voulez que le membre soit quelque chose qui soit interne à la classe, au package, à la hiérarchie de la classe ou pas du tout interne, et choisissez le niveau d'accès en conséquence.

Exemples:

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

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

                | 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 ce qui est privé. Ensuite, progressez vers le public à 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. La première est quelque chose que vous voulez éviter car cela 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 surcharger les implémentations de méthodes en sous-classant; c'est trop facile de bousiller la logique. Déclarez les méthodes abstraites protégées si vous souhaitez qu’elles soient remplacées.

Utilisez également l'annotation @Override lors du remplacement pour éviter que des objets ne se brisent lors de la refactorisation.

C’est en fait un peu plus compliqué qu’une simple grille. La grille vous indique si un accès est autorisé, mais en quoi consiste exactement un accès? De plus, les niveaux d'accès interagissent avec les classes imbriquées et l'héritage de manière complexe.

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

Résumé

Un accès à un membre avec ce spécificateur d'accès est-il autorisé?

Le membre est privé : uniquement si membre est défini dans la même classe que le code appelant.
Le membre est un paquet privé: uniquement si le code appelant est dans le paquet contenant immédiatement le membre.
Le membre est protégé : Même paquet, ou si membre est défini dans une superclasse de la classe contenant le code appelant.
le membre est public : oui.

À quels spécificateurs d'accès s'appliquent

Les variables locales et les paramètres formels ne peuvent pas prendre de spécificateurs d'accès. Étant donné qu’elles sont intrinsèquement inaccessibles à l’extérieur conformément aux règles d’étendue, elles sont en réalité privées.

Pour les classes situées dans la partie 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 package (il n'y a pas d'héritage des packages).

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

En relation: Accessibilité des classes Java

Commande

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

public > protégé > paquet-privé > privé

signifie que public fournit le plus grand accès, privé le moins. Toute référence possible sur un membre privé est également valable pour un membre package-private; toute référence à un membre package-private est valide sur un membre protégé, etc. (Donner l'accès aux membres protégés à d'autres classes du même package é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 du 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 avec private [this] .)
Vous devez avoir accès à 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 fabriques statiques ou des initialiseurs de variables statiques). De même pour les constructeurs privés ou protégés par paquets.
- Le fait d'avoir uniquement des constructeurs privés signifie également que la classe ne peut pas être sous-classée en externe, car Java requiert des constructeurs d'une sous-classe d'appeler implicitement ou explicitement un constructeur de superclasse. (Il peut toutefois contenir une classe imbriquée qui la sous-classe.)

Classes internes

Vous devez également tenir compte des portées 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. Ainsi, vous pouvez avoir une classe interne privée avec un membre public; le membre peut-il être consulté? (Voir ci-dessous.) La règle générale consiste à examiner la portée et à réfléchir de manière récursive pour voir si vous pouvez accéder à chaque niveau.

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

Pour avoir un aperçu de leur interaction, considérons cet exemple. Il est possible de "fuir" classes internes privées; c'est habituellement 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

Quelques questions connexes:

Java - Accessibilité des méthodes dans la classe package-private??

En règle générale:

private : étendue de la classe.
par défaut (ou package-private ): étendue du package.
protected : portée du paquet + enfant (comme le paquet, mais nous pouvons le sous-classer à partir de paquets différents). Le modificateur protected conserve toujours le " parent-enfant " relation.
public : partout.

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

(D) irect (invoquer à partir d'une méthode de la même classe ou via la syntaxe "this").
(R) eference (invoquez une méthode à l'aide d'une référence à la classe ou via la syntaxe "dot").
(I) héritage (via un 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 court

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

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, où les sous-classes peuvent le voir. Mais comment? Voici un exemple qui, espérons-le, clarifie la confusion:

Supposons que nous avons 2 classes; Père et Fils , chacun dans son propre package:

package fatherpackage;

public class Father
{

}

-------------------------------------------

package sonpackage;

public class Son extends Father
{

}

Ajoutons une méthode protégée foo () à Père .

package fatherpackage;

public class Father
{
    protected void foo(){}
}

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

À l'intérieur d'une classe située dans le même package que celui où foo () est défini ( fatherpackage ):

package fatherpackage;

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

Dans 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();
    }
}

Sur une référence dont le type est de 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();
    }
}

Sur une référence dont le type est la classe parente et à l'intérieur du package 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 parente et en dehors du package dans lequel 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 package d'une sous-classe (une sous-classe hérite des membres protégés de son parent et les rend privés à des 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

Le modificateur d'accès privé est le niveau d'accès le plus restrictif. Les classes 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 de lecture 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 qu'aux sous-classes d'un autre package ou de 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 aux interfaces.

Les méthodes, 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 une chance d'utiliser la méthode d'assistance ou la variable, tout en empêchant une classe non apparentée d'essayer de l'utiliser.

Public

Une classe, une méthode, un constructeur, une interface, etc. déclarée publique, est accessible depuis n’importe quelle autre classe.

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

Différents packages

Toutefois, si la classe publique à laquelle vous essayez d'accéder est dans un package différent, elle 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 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 packages

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

Remarque

Nous ne pouvons pas remplacer les champs statiques. Si vous essayez de les remplacer, aucune erreur ne s'affiche. mais cela ne fonctionne pas ce que nous exceptons.

Réponses associées

Remplacement des méthodes statiques en java

Liens de références

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

Privé : accès limité aux classes uniquement

Par défaut (aucun modificateur) : accès limité à la classe et au package

Protégé : accès limité à la classe, au package et aux sous-classes (package interne et externe)

Public : accessible aux classes, aux packages (tous) et aux sous-classes ... En bref, partout.

La différence se trouve dans les liens déjà fournis, mais celui à utiliser revient généralement au "Principe de moindre connaissance". N'autorisez que la visibilité minimale nécessaire.

Les modificateurs d'accès permettent de restreindre l'accès à plusieurs niveaux.

Public: C’est aussi simple que vous pouvez y accéder depuis n'importe quelle classe, que celle-ci se trouve ou non dans le même package.

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

Par défaut: il est accessible dans le même package à partir de n'importe quelle classe de package.

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.

Protégé: , vous pouvez accéder aux variables du même package ainsi qu'à la sous-classe de tout autre package. Donc, fondamentalement, il s'agit du comportement par défaut + hérité .

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

Privé: il peut être accessible dans la même classe.

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

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:

Uniquement accessible 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

Peut être 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: Bonjour

3. Privé

Accessible uniquement dans la même classe.

Si vous essayez d'accéder aux membres privés d'une classe sur une autre, une erreur de compilation se produira. 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

Je veux juste aborder un détail qui est extrêmement souvent erroné, y compris par la plupart des réponses fournies sur cette page. " Par défaut " access (quand aucun modificateur d'accès n'est présent) n'est pas toujours identique à package-private . 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 des paquets privés par défaut. ( JLS & # 167; 6.6.1 )
Les membres de classe et les constructeurs sont paquet-private par défaut. ( JLS & # 167; 6.6.1 )
constructeurs d’énumération sont privés par défaut . (En effet, les enum constructeurs doivent être privés, et tenter de les rendre publics ou protégés est une erreur.) Les constantes Enum sont publiques et n'autorisent aucun spécificateur d'accès. Les autres membres des enums sont package-private par défaut. ( JLS & # 167; 8,9 )
Tous les membres des types d'interface et d'annotation sont publics par défaut . (En effet, les membres des interfaces et des types d'annotation doivent être publics, et tenter de les rendre privés ou protégés est une erreur.) (JLS & # 167; 9.3 à 9.5 )

public : accessible de n’importe où dans l’application.
par défaut - accessible depuis le package.
protected : accessible à partir du package et des sous-classes d'un autre package. aussi bien
private - accessible uniquement à partir de sa classe.

Visible dans le package. Le défaut. Aucun modificateur n'est nécessaire.

Visible uniquement par la classe ( privé ).

Visible dans le monde ( public ).

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

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, les variables et les constructeurs déclarés privés ne sont accessibles que dans la classe déclarée elle-même. Le modificateur d'accès privé est le niveau d'accès le plus restrictif. Les classes 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 de lecture publiques sont présentes dans la classe.

L'utilisation du modificateur privé est le moyen principal par lequel un objet s'encapsule et cache 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:

Une classe, une méthode, un constructeur, une interface, etc. déclarée publique peut être accessible à partir de toute autre classe. Par conséquent, les champs, méthodes et blocs déclarés dans une classe publique sont accessibles à partir de toute classe appartenant à l'univers Java.

Toutefois, si la classe publique à laquelle vous essayez d'accéder se trouve dans un package différent, elle 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 ses sous-classes.

Exemple:

public void cal(){

}

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

Les variables, méthodes et constructeurs déclarés protégés dans une superclasse ne sont accessibles qu'aux sous-classes d'un autre package ou de toute classe du package 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. Toutefois, les méthodes et les champs d'une interface ne peuvent pas être déclarés protégés.

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

class Van{

    protected boolean speed(){

    }
}

class Car{
    boolean speed(){
    }

}

Cette page décrit bien les informations protégées ; modificateur d'accès par défaut

.... Protected: Le modificateur d'accès protégé est un peu compliqué 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é et qui sont en dehors du package dans lequel la classe parente est présente.

Mais ces membres protégés ne sont & # 8220; accessibles en dehors du package que par héritage "# 8220 ;. Cela signifie que vous pouvez accéder directement à un membre protégé d'une classe de sa sous-classe présente dans un autre package, comme si ce 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 parente. ....

La réponse de David fournit la signification de chaque modificateur d'accès. Pour ce qui est de savoir quand utiliser chacune d’elles, je suggère de rendre publiques toutes les classes et les méthodes de chaque classe destinées à un usage externe (son API), ainsi que tout ce qui est privé.

Avec le temps, vous comprendrez quand rendre certaines classes privées à un paquet et quand déclarer certaines méthodes protégées pour utilisation dans des sous-classes.

Remarque: Ceci n'est qu'un supplément pour la réponse acceptée.

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

De Modificateurs d'accès Java :

Un modificateur d'accès Java spécifie les classes pouvant accéder à une donnée donnée.   classe et ses champs, constructeurs et méthodes. Les modificateurs d'accès peuvent   être spécifiés séparément pour une classe, ses constructeurs, ses champs et   méthodes. Les modificateurs d’accès Java sont aussi parfois mentionnés quotidiennement   speech en tant que spécificateurs d'accès Java, mais le nom correct est Java Access   modificateurs. 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 liste

privé

default (package)

protégé

public

D'après les Contrôle de l'accès aux membres d'une classe :

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


Au niveau supérieur - public ou package-private (sans modificateur explicite).

Au niveau du membre: public, privé, protégé ou paquet-privé (sans modificateur explicite).


Une classe peut être déclarée avec le modificateur public, auquel cas   La classe est visible par toutes les classes du monde. Si une classe n'a pas de modificateur   (la valeur par défaut, également connue sous le nom de package-private), elle n'est visible que   dans son propre paquet

Le tableau suivant montre l'accès aux membres autorisé par chaque utilisateur.   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 à ses propres membres. La deuxième colonne indique si   classes dans le même package que la classe (indépendamment de leur   parenté) ont accès au membre. La troisième colonne indique   si les sous-classes de la classe déclarées en dehors de ce paquet ont   accès au membre. La quatrième colonne indique si toutes les classes   avoir accès au membre.

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

Public Protected Par défaut et private sont des modificateurs d'accès.

Ils sont destinés à être encapsulés ou à masquer et afficher le contenu de la classe.

La classe peut être publique ou par défaut
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 La valeur par défaut est accessible uniquement dans le package. Protégé dans le package ainsi que dans toute classe qui l'étend. Le public est ouvert à tous.

Normalement, les variables de membre sont définies comme privées, mais les méthodes de membre sont publiques.

Souvent, j'ai réalisé que la création d'analogies du monde réel permettait de se souvenir des concepts de base de toute langue. Voici mon analogie pour comprendre les modificateurs d'accès en Java:

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

Lorsque vous l'amenez sur le campus, la première chose que vous et votre ami voyez est cette statue. Cela signifie que quiconque se promène sur le campus peut regarder la statue sans la permission de l'université. Cela rend la statue PUBLIC .
Ensuite, vous voulez emmener votre ami dans votre dortoir, mais pour cela, vous devez l'enregistrer en tant que visiteur. Cela signifie qu’il obtient un passe d’accès (identique à celui que vous possédez) pour entrer dans divers bâtiments du campus. Cela rendrait sa carte d'accès comme PROTÉGÉ .
Votre ami souhaite se connecter au réseau WiFi du campus mais ne dispose pas des informations d'identification pour le faire. La seule façon dont il peut se connecter est si vous partagez vos identifiants avec lui. (N'oubliez pas que chaque étudiant qui va à l'université possède également ces informations de connexion). Vos identifiants de connexion seront alors PAS DE MODIFICATEUR .
Enfin, votre ami souhaite lire votre rapport d’avancement pour le semestre publié sur le site Web. Cependant, chaque étudiant possède son propre identifiant personnel pour accéder à cette section du site Web du campus. Cela rendrait ces informations d'identification en tant que PRIVÉ .

J'espère que ça aide!

Lorsque vous songez aux modificateurs d'accès, réfléchissez-y simplement de cette façon (s'applique aux variables et aux méthodes ):

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

Maintenant, la confusion règne en ce qui concerne par défaut et protégé

défaut - > 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 à l'extérieur de ce package, vous pouvez y accéder.

protected - > Légèrement moins strict que default et en dehors des mêmes classes de packages, il est accessible aux sous-classes situées en dehors du package indiqué.

Tout est question d’ encapsulation (ou, comme le dit Joe Phillips, connaissances minimales ).

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

Nous utilisons tous des modificateurs de méthode et de membre tels que privé, public, ... mais un nombre insuffisant de développeurs utilise des packages pour organiser le code de manière logique.

Par exemple: Vous pouvez placer des méthodes de sécurité sensibles dans un package "sécurité". Ensuite, placez une classe publique qui accède à une partie du code lié à la sécurité dans ce package mais conserve les autres classes de sécurité package private . Ainsi, les autres développeurs ne pourront utiliser la classe accessible au public qu'en dehors de ce paquetage (à moins qu'ils ne modifient le modificateur). Ce n'est pas une fonctionnalité de sécurité, mais guidera son utilisation.

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

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

Si, au contraire, vous définissez tout comme public , vous ne saurez pas clairement ce qui devrait ou ne devrait pas être consulté, ce qui peut conduire à l'écriture de nombreux javadoc (ce qui n'impose rien via le compilateur ...).

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow