En Java, différence entre le package privé, public, protégé et privé

En Java, existe-t-il des règles claires sur l’utilisation de chacun des modificateurs d’access, à savoir le par défaut (package privé), public , protected et private , tout en créant class et interface et traitement de l’inheritance?

    Le tutoriel officiel peut vous être utile.

                 │ Classe │ Package │ Sous-classe │ Sous-classe │ Monde
                 Same │ │ (même paquet) │ (diff pkg) │ 
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     public │ + │ + │ + │ + │ +     
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     protégé │ + │ + │ + │ + │         
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     aucun modificateur │ + │ + │ + │ │    
     ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
     privé │ + │ │ │ │    
    
     +: accessible
     blanc: non accessible
    

    (Attention: je ne suis pas un programmeur Java, je suis un programmeur Perl. Perl n’a aucune protection formelle, 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.

    Package 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 de Java (que certains considèrent comme une erreur).

    Protégé

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

    Publique

    Tout le monde peut le voir.

    Publié

    Visible en dehors du code que je contrôle. (Bien que n’étant pas une syntaxe Java, il est important 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 d’encapsuler les informations. Autant que possible, vous voulez masquer le détail de la manière dont les utilisateurs font quelque chose. Pourquoi? Car alors vous pouvez les changer plus tard et ne pas casser le code de quelqu’un. Cela vous permet d’optimiser, de réorganiser, de repenser et de corriger les bogues sans craindre 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 être. Commencez avec private et ajoutez seulement plus de visibilité si nécessaire. Ne rendez public que ce que l’utilisateur a absolument besoin de savoir, chaque détail vous empêchera de repenser le système.

    Si vous voulez que les utilisateurs puissent personnaliser les comportements, plutôt que de rendre publics les composants internes afin de pouvoir les remplacer, il est souvent préférable d’introduire ces entrailles dans un object et de rendre cette interface publique. De cette façon, ils peuvent simplement twigr un nouvel object. Par exemple, si vous écriviez un lecteur de CD et que vous vouliez que le bit “rechercher des informations sur ce CD” soit personnalisable, plutôt que de rendre ces méthodes publiques, vous metsortingez toutes ces fonctionnalités dans son propre object et . De cette manière, être avare d’exposer vos entrailles encourage une bonne composition et une séparation des préoccupations.

    Personnellement, je rest avec juste “privé” et “public”. Beaucoup de langues OO ont juste ça. “Protected” peut être pratique, mais c’est vraiment une sortingche. Une fois qu’une interface est plus que privée, elle est hors de votre contrôle et vous devez chercher dans le code d’autres personnes pour trouver des utilisations.

    C’est là que l’idée de “publication” entre en jeu. Changer une interface (la refactoriser) nécessite que vous trouviez tout le code qui l’utilise et que cela change aussi. Si l’interface est privée, 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 du code d’entreprise destiné à un usage interne, peu importe si une interface est publique. Vous pouvez récupérer tout le code hors du référentiel d’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 arraché. Vous devez prendre en charge cette interface ou votre code de risque. Même les interfaces protégées peuvent être considérées comme publiées (ce qui explique pourquoi je ne me soucie pas de la protection).

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

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

    Modificateurs d'accès Java

    Des explications

    • Un membre privé est uniquement accessible dans la même classe que celle déclarée.

    • Un membre sans modificateur d’access est uniquement accessible dans les classes du même package.

    • Un membre protégé est accessible dans toutes les classes du même package et dans les sous-classes des autres packages.

    • Un membre public 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?

    Les modificateurs d’access sont un outil qui vous aide à empêcher toute interruption accidentelle de l’encapsulation (*) . Demandez-vous si vous souhaitez que le membre soit interne à la classe, au package, à la hiérarchie des classes ou pas du tout interne, et choisissez le niveau d’access en conséquence.

    Exemples:

    • Un champ long internalCounter devrait probablement être privé puisqu’il est modifiable et un détail d’implémentation.
    • Une classe qui ne devrait être instanciée que dans une classe de fabrique (dans le même paquet) devrait avoir un constructeur restreint par paquet, car il ne devrait pas être possible de l’appeler directement en dehors du paquet.
    • Une méthode interne void beforeRender() appelée juste avant le rendu et utilisée comme hook dans les sous-classes doit être protégée.
    • Une 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 ensuite, progressez vers le public au fur et à mesure des besoins et 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 substituer des implémentations de méthodes en sous-classant; c’est trop facile de bousiller la logique. Déclarez les méthodes protégées abstraites si vous souhaitez qu’elles soient remplacées.

    De plus, utilisez l’annotation @Override lors de la substitution pour éviter que les choses ne se cassent lorsque vous refactorisez.

    C’est en fait un peu plus compliqué qu’une simple grid montre. La grid vous indique si un access est autorisé, mais qu’est-ce qui constitue exactement un access? En outre, les niveaux d’access interagissent de manière complexe avec les classes nestedes et l’inheritance.

    L’access “par défaut” (spécifié par l’absence d’un mot clé) est également appelé package-private . Exception: dans une interface, aucun modificateur ne signifie un access public; les modificateurs autres que publics sont interdits. Les constantes énumérées sont toujours publiques.

    Résumé

    Est-ce qu’un access à un membre avec ce spécificateur d’access est autorisé?

    • Member est private : Seulement si member est défini dans la même classe que le code d’appel.
    • Le membre est un package privé: uniquement si le code d’appel se trouve dans le package contenant le membre immédiatement.
    • Member is protected : Même package, ou si member est défini dans une super-classe de la classe contenant le code appelant.
    • Le membre est public : oui.

    Quels spécificateurs d’access s’appliquent à

    Les variables locales et les parameters formels ne peuvent pas prendre de spécificateurs d’access. Comme ils sont insortingnsèquement inaccessibles à l’extérieur selon les règles de scope, ils sont effectivement privés.

    Pour les classes de la scope supérieure, seuls public et package-private sont autorisés. Ce choix de conception est probablement dû au fait que protected et private serait redondant au niveau du package (il n’ya pas d’inheritance des packages).

    Tous les spécificateurs d’access sont possibles sur les membres de classe (constructeurs, méthodes et fonctions de membre statique, classes nestedes).

    Related: Accessibilité de la classe Java

    Commande

    Les spécificateurs d’access peuvent être ssortingctement ordonnés

    public> protected> package-private> private

    ce qui signifie que le public fournit le plus d’access, private le moins. Toute référence possible sur un membre privé est également valable pour un membre du paquet privé. toute référence à un membre package-private est valide sur un membre protégé, etc. (Donner access aux membres protégés à d’autres classes du même package était considéré comme une erreur.)

    Remarques

    • Les méthodes d’une classe sont autorisées à accéder aux membres privés d’autres objects de la même classe. Plus précisément, une méthode de classe C peut accéder à des membres privés de C sur des objects de n’importe quelle sous-classe de C. Java ne prend pas en charge la ressortingction d’access par instance, uniquement par classe. (Comparez avec Scala, qui le supporte en utilisant private[this] .)
    • Vous devez avoir access à un constructeur pour construire un object. Ainsi, si tous les constructeurs sont privés, la classe ne peut être construite que par un code résidant dans la classe (généralement des méthodes d’usine statiques ou des initialiseurs de variables statiques). De même pour les constructeurs de paquets privés ou protégés.
      • 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 requirejs que les constructeurs d’une sous-classe appellent implicitement ou explicitement un constructeur de super-classe. (Il peut cependant contenir une classe nestede qui le sous-classe.)

    Classes internes

    Vous devez également tenir compte des scopes nestedes , telles que les classes internes. Un exemple de complexité est que les classes internes ont des membres qui peuvent eux-mêmes prendre des modificateurs d’access. Vous pouvez donc 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 est de regarder la scope et de penser de manière récursive pour voir si vous pouvez accéder à chaque niveau.

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

    Pour un aperçu de leur interaction, considérez cet exemple. Il est possible de “fuir” les classes internes privées; c’est généralement un avertissement:

     class Test { public static void main(final Ssortingng ... 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é de la méthode dans la classe package-private?

    En règle générale:

    • private : étendue de classe.
    • default (ou package-private ): étendue du paquet.
    • protected : package scope + child (comme package, mais nous pouvons le sous-classer à partir de différents packages). Le modificateur protected conserve toujours la relation “parent-enfant”.
    • public : partout.

    Par conséquent, si nous divisons le droit d’access en trois droits:

    • (D) irect (invoquer depuis une méthode dans la même classe).
    • (R) eference (invoquer une méthode utilisant une référence à la classe ou via la syntaxe “point”).
    • (I) inheritance (par sous- classement ).

    alors nous avons ce tableau simple:

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

    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 (pas de modificateur spécifié): accessible par les classes du même package.
    • private : accessible uniquement dans la même classe.

    Le modificateur d’access le plus mal compris de Java est protected . Nous soaps qu’il 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 2 classes; Father et Son , chacun 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 dans 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 actuelle via this ou this 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 qui se trouve dans le paquet où 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 qui est en dehors du package 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 paquetage 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, les variables et les 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’access privé est le niveau d’access le plus ressortingctif. La classe et les interfaces ne peuvent pas être privées.

    Remarque

    Les variables déclarées privées peuvent être 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 super-classe sont accessibles uniquement par les 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’access 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, cependant les méthodes et les champs d’une interface ne peuvent pas être déclarés protégés.

    Remarque

    L’access 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 associée d’essayer de l’utiliser.


    Publique

    Une classe, une méthode, un constructeur, une interface, etc. déclarés publics peuvent être accédés depuis n’importe quelle autre classe.

    Par conséquent, les champs, méthodes, blocs déclarés à l’intérieur d’une classe publique sont accessibles à partir de toute 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 encore être imscope.

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


    Default -No mot-clé:

    Le modificateur d’access par défaut signifie que nous ne déclarons pas explicitement de modificateur d’access pour une classe, un champ, une méthode, etc.

    • Dans les mêmes forfaits

    Une variable ou une méthode déclarée sans aucun modificateur de contrôle d’access est disponible pour toute autre classe du même package. Les champs d’une interface sont implicitement publics statiques finaux et les méthodes d’une interface sont publiques par défaut.

    Remarque

    Nous ne pouvons pas remplacer les champs statiques.si vous essayez de les remplacer, cela ne montre aucune erreur, mais cela ne fonctionne pas.

    Réponses connexes

    • 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

    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 connaissance minimale”. N’autorisez que le moins de visibilité nécessaire.

    Privé : access limité à la classe uniquement

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

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

    Public : accessible à la classe, au package (all) et aux sous-classes … En bref, partout.

    Modificateurs d’access en Java.

    Les modificateurs d’access Java sont utilisés pour fournir un contrôle d’access en Java.

    1. Par défaut:

    Accessible aux classes dans le même package uniquement.

    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(Ssortingng args[]){ A obj = new A(); // Comstack Time Error obj.msg(); // Comstack Time Error } } 

    Cet access est plus restreint que public et protégé, mais moins restreint que privé.

    2. Public

    Peut être accédé de n’importe où. (Accès global)

    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(Ssortingng args[]){ A obj = new A(); obj.msg(); } } 

    Sortie: Bonjour

    3. privé

    Accessible uniquement dans la même classe.

    Si vous essayez d’accéder à des membres privés d’une classe dans une autre, vous générerez une erreur de compilation. Par exemple,

     class A{ private int data = 40; private void msg(){System.out.println("Hello java");} } public class Simple{ public static void main(Ssortingng args[]){ A obj = new A(); System.out.println(obj.data); // Comstack Time Error obj.msg(); // Comstack 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(Ssortingng args[]){ B obj = new B(); obj.msg(); } } 

    Sortie: Bonjour

    Entrez la description de l'image ici

    Les modificateurs d’access sont là pour restreindre l’access à plusieurs niveaux.

    Public: Il est fondamentalement aussi simple que vous pouvez accéder depuis n’importe quelle classe, que ce soit dans le même package ou non.

    Pour accéder si vous êtes dans le même paquet, vous pouvez accéder directement, mais si vous êtes dans un autre paquet, vous pouvez créer un object 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 object de la classe. Mais vous ne pouvez pas accéder à cette variable en dehors du package.

    Protected: vous pouvez accéder aux variables dans le même package et sous-classe dans tout autre package. donc fondamentalement c’est le 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 object de classe enfant.

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

    Dans les méthodes non statiques, vous pouvez accéder directement grâce à cette référence (également dans les constructeurs) mais pour accéder à des méthodes statiques dont vous avez besoin pour créer un object de la classe.

    Visible à l’emballage. Le défaut. Aucun modificateur n’est nécessaire.

    Visible à la classe seulement ( privé ).

    Visible au monde ( public ).

    Visible à l’emballage 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:

     Ssortingng name = "john"; public int age(){ return age; } 

    Modificateur d’access privé – privé:

    Les méthodes, variables et constructeurs déclarés privés ne sont accessibles que dans la classe déclarée elle-même. Le modificateur d’access privé est le niveau d’access le plus ressortingctif. La classe et les interfaces ne peuvent pas être privées.

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

    L’utilisation du modificateur private est le principal moyen par lequel un object s’encapsule et masque les données du monde extérieur.

    Exemples:

     Public class Details{ private Ssortingng name; public void setName(Ssortingng n){ this.name = n; } public Ssortingng getName(){ return this.name; } } 

    Modificateur d’access public – public:

    Une classe, une méthode, un constructeur, une interface, etc. déclarés publics peuvent être accédés 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 toute classe appartenant à l’univers Java.

    Cependant, si la classe publique à laquelle nous tentons d’accéder se trouve dans un package différent, la classe publique doit encore être imscope.

    Because of class inheritance, all public methods and variables of a class are inherited by its subclasses.

    Exemple:

     public void cal(){ } 

    Protected access modifier – protected:

    Variables, methods and constructors which are declared protected in a superclass can be accessed only by the subclasses in another package or any class within the package of the protected members’ class.

    The protected access modifier cannot be applied to class and interfaces. Methods, fields can be declared protected, however methods and fields in a interface cannot be declared protected.

    Protected access gives the subclass a chance to use the helper method or variable, while preventing a nonrelated class from trying to use it.

     class Van{ protected boolean speed(){ } } class Car{ boolean speed(){ } } 

    I just want to address a detail that is extremely commonly got wrong, including by most of the answers on this page. “Default” access (when no access modifier is present) is not always the same as package-private . It depends on what the thing is.

    • Non-member types (that is, classes, enums, interfaces, and annotation types not declared inside another type) are package-private by default. ( JLS §6.6.1 )

    • Class members and constructors are package-private by default. ( JLS §6.6.1 )

    • Enum constructors are private by default . (Indeed, enum contructors must be private, and it is an error to try to make them public or protected). Enum constants are public, and do not allow any access specifier. Other members of enums are package-private by default. ( JLS §8.9 )

    • All members of interfaces and annotation types are public by default . (Indeed, members of interfaces and annotation types must be public, and it is an error to try to make them private or protected.) ( JLS §9.3 to 9.5 )

    This page writes well about the protected & default access modifier

    …. Protected: Protected access modifier is the a little sortingcky and you can say is a superset of the default access modifier. Protected members are same as the default members as far as the access in the same package is concerned. The difference is that, the protected members are also accessible to the subclasses of the class in which the member is declared which are outside the package in which the parent class is present.

    But these protected members are “accessible outside the package only through inheritance“. ie you can access a protected member of a class in its subclass present in some other package directly as if the member is present in the subclass itself. But that protected member will not be accessible in the subclass outside the package by using parent class’s reference. ….

    • public – accessible from anywhere in the application.

    • default – accessible from package.

    • protected – accessible from package and sub-classes in other package. as well

    • private – accessible from its class only.

    David’s answer provides the meaning of each access modifier. As for when to use each, I’d suggest making public all classes and the methods of each class that are meant for external use (its API), and everything else private.

    Over time you’ll develop a sense for when to make some classes package-private and when to declare certain methods protected for use in subclasses.

    • Visible to the package. the default . No modifiers are needed.
    • Visible to the class only; private .
    • Visible to the world; public .
    • Visible to the package and all subclasses; protected .

    So let’s talk about Access Control and Inheritance The following rules for inherited methods are,

    • Methods declared public in a superclass also must be public in all subclasses.
    • Methods declared protected in a superclass must either be protected or public in subclasses; they cannot be private.
    • Methods declared without access control (no modifier was used) can be declared more private in subclasses.
    • Methods declared private are not inherited at all, so there is no rule for them.

    Note: This is just a supplement for the accepted answer.

    This is related to Java Access Modifiers .

    From Java Access Modifiers :

    A Java access modifier specifies which classes can access a given class and its fields, constructors and methods. Access modifiers can be specified separately for a class, its constructors, fields and methods. Java access modifiers are also sometimes referred to in daily speech as Java access specifiers, but the correct name is Java access modifiers. Classes, fields, constructors and methods can have one of four different Java access modifiers:

    • Élément de la liste
    • privé
    • default (package)
    • protégé
    • Publique

    From Controlling Access to Members of a Class tutorials:

    Access level modifiers determine whether other classes can use a particular field or invoke a particular method. There are two levels of access control:

    • At the top level—public, or package-private (no explicit modifier).
    • At the member level—public, private, protected, or package-private (no explicit modifier).

    A class may be declared with the modifier public, in which case that class is visible to all classes everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package

    The following table shows the access to members permitted by each modifier.

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

    The first data column indicates whether the class itself has access to the member defined by the access level. As you can see, a class always has access to its own members. The second column indicates whether classes in the same package as the class (regardless of their parentage) have access to the member. The third column indicates whether subclasses of the class declared outside this package have access to the member. The fourth column indicates whether all classes have access to the member.

    Access levels affect you in two ways. First, when you use classes that come from another source, such as the classes in the Java platform, access levels determine which members of those classes your own classes can use. Second, when you write a class, you need to decide what access level every member variable and every method in your class should have.

    Public Protected Default and private are access modifiers.

    They are meant for encapsulation, or hiding and showing contents of the class.

    1. Class can be public or default
    2. Class members can be public, protected, default or private.

    Private is not accessible outside the class Default is accessible only in the package. Protected in package as well as any class which extends it. Public is open for all.

    Normally, member variables are defined private, but member methods are public.

    Often times I’ve realized that remembering the basic concepts of any language can made possible by creating real-world analogies. Here is my analogy for understanding access modifiers in Java:

    Let’s assume that you’re a student at a university and you have a friend who’s coming to visit you over the weekend. Suppose there exists a big statue of the university’s founder in the middle of the campus.

    • When you bring him to the campus, the first thing that you and your friend sees is this statue. This means that anyone who walks in the campus can look at the statue without the university’s permission. This makes the statue as PUBLIC .

    • Next, you want to take your friend to your dorm, but for that you need to register him as a visitor. This means that he gets an access pass (which is the same as yours) to get into various buildings on campus. This would make his access card as PROTECTED .

    • Your friend wants to login to the campus WiFi but doesn’t have the any credentials to do so. The only way he can get online is if you share your login with him. (Remember, every student who goes to the university also possesses these login credentials). This would make your login credentials as NO MODIFIER .

    • Finally, your friend wants to read your progress report for the semester which is posted on the website. However, every student has their own personal login to access this section of the campus website. This would make these credentials as PRIVATE .

    J’espère que cela t’aides!

    When you are thinking of access modifiers just think of it in this way (applies to both variables and methods ):

    public –> accessible from every where
    private –> accessible only within the same class where it is declared

    Now the confusion arises when it comes to default and protected

    default –> No access modifier keyword is present. This means it is available ssortingctly within the package of the class. Nowhere outside that package it can be accessed.

    protected –> Slightly less ssortingcter than default and apart from the same package classes it can be accessed by sub classes outside the package it is declared.

    It is all about encapsulation (or as Joe Phillips stated, least knowledge ).

    Start with the most ressortingctive (private) and see if you need less ressortingctive modifiers later on.

    We all use method and member modifiers like private, public, … but one thing too few developers do is use packages to organize code logically.

    For example: You may put sensitive security methods in a ‘security’ package. Then put a public class which accesses some of the security related code in this package but keep other security classes package private . Thus other developers will only be able to use the publicly available class from outside of this package (unless they change the modifier). This is not a security feature, but will guide usage.

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

    Another thing is that classes which depend a lot on each other may end up in the same package and could eventually be refactored or merged if the dependency is too strong.

    If on the contrary you set everything as public it will not be clear what should or should not be accessed, which may lead to writing a lot of javadoc (which does not enforce anything via the comstackr…).