(Attention: je ne suis pas un programmeur Java, je suis un programmeur Perl. Perl n'a pas de protections formelles, c'est peut-être pourquoi je comprends si bien le problème :))
Privé
Comme vous le pensez, seule la classe dans laquelle il est déclaré peut le voir.
Forfait privé
Il ne peut être vu et utilisé que par le package 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é
Le package Private + peut être vu par les sous-classes ou les membres du package.
Publique
Tout le monde peut le voir.
Visible en dehors du code que je contrôle. (Bien que n'étant pas une syntaxe Java, elle est importante pour cette discussion).
C ++ définit un niveau supplémentaire appelé "ami" et moins vous en savez, mieux c'est.
Quand devez-vous utiliser quoi? L'idée est d'encapsuler pour cacher des informations. Autant que possible, vous souhaitez masquer le détail de la façon dont quelque chose est fait à vos utilisateurs. Pourquoi? Parce qu'alors vous pouvez les changer plus tard et ne casser le code de personne. Cela vous permet d'optimiser, de refactoriser, de repenser et de corriger les bogues sans vous soucier que quelqu'un utilise ce code que vous venez de réviser.
Donc, la règle de base est de rendre les choses aussi visibles qu'elles doivent l'être. Commencez avec privé et ajoutez seulement plus de visibilité si nécessaire. Ne rendez public que ce qui est absolument nécessaire à l'utilisateur, chaque détail que vous rendez public restreint votre capacité à repenser le système.
Si vous souhaitez que les utilisateurs soient en mesure de personnaliser les comportements, plutôt que de rendre les internes publics afin qu'ils puissent les remplacer, il est souvent préférable de pousser ces tripes dans un objet et de rendre cette interface publique. De cette façon, ils peuvent simplement brancher un nouvel objet. Par exemple, si vous écriviez un lecteur de CD et que vous vouliez que le bit "aller chercher des informations sur ce CD" soit personnalisable, plutôt que de rendre ces méthodes publiques, vous mettriez toutes ces fonctionnalités dans son propre objet et ne rendriez public que votre getter / setter d'objet . De cette façon, être avare d'exposer vos tripes encourage une bonne composition et une séparation des préoccupations
Personnellement, je reste fidèle à "privé" et "public". De nombreuses langues OO l'ont juste. "Protégé" peut être pratique, mais c'est vraiment une triche. Une fois qu'une interface est plus que privée, elle est hors de votre contrôle et vous devez chercher dans le code des autres pour trouver des utilisations.
C'est là que l'idée de «publié» entre en jeu. Changer une interface (la refactoriser) nécessite que vous trouviez tout le code qui l'utilise et que vous le changiez aussi. Si l'interface est privée, eh bien pas de problème. S'il 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. Parfois, cela est possible, par exemple, si vous travaillez sur un code d'entreprise à usage interne, peu importe si une interface est publique. Vous pouvez récupérer tout le code du référentiel d'entreprise. Mais si une interface est "publiée", s'il y a du code qui l'utilise hors de votre contrôle, alors vous êtes arrosé. Vous devez prendre en charge cette interface ou risquer de casser le code. Même les interfaces protégées peuvent être considérées comme publiées (c'est pourquoi je ne '
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 traits , mais c'est un autre spectacle.
private
masque les autres classes du package.public
expose à des classes en dehors du package.protected
est une version depublic
restreinte uniquement aux sous-classes.