Voilà, je suis en BTS IG.
Donc on a commencé la POO et le langage Java, et j'ai beaucoup de mal à comprendre l'intérêt de définir une variable en Private et pourquoi il faudrait utiliser des méthodes pour pouvoir modifier le contenu de la variable    
 
Pourquoi pas directement tout définir en Public plutôt que de devoir créer des méthodes pour aller modifiers le contenu de la variable ???
 
Ca fait longtemps que j'essaye de comprendre mais malgrés ça je saisi toujours pas l'intérêt.
 
P.S : Je sais que je vais passer pour le boulet de service, enfin tampis  

L'intérêt c'est que les classes sont réutilisables, et pas forcément par toi. Et que dans l'implémentation tu as besoin, soit de variables internes que le reste du monde n'a même pas besoin de savoir qu'elles existent, soit de variables dont le contenu doit être contrôlé pour éviter que la classe ne fasse n'importe quoi (ou bien que tu as besoin d'effectuer des actions lors de la mise à jour de la variable).
Dans ces deux cas, définir la variable comme "private" est un moyen simple de gérer tranquillement ta tambouille.

Et il est de toute façon plus sage de passer toutes les variables en private et d'écrire les méthodes pour y accéder, même si c'est de l'inline type "return variable;".
Pour deux raisons :
1) tu contrôles les accès à tes variables dès la conception, et ça c'est déjà un moyen d'améliorer la maintenabilité (tu découvriras vite que pouvoir modifier un programme 6 mois après l'avoir délaissé est un facteur important)
2) tu développes une classe qui est utilisée par des gens, puis tu découvres que tu as besoin de ne mettre dans ta variable que des valeurs précises, pour une raison x ou y. Si ta variable est publique, tu dois la passer en private et écrire les méthodes qui vont bien, et lors de la mise à jour de ta classe, plus rien ne fonctionne chez tes utilisateurs (utilisateur == ça peut être toi, aussi). Si ta méthode existe déjà, t'as plus qu'à en modifier le comportement, c'est (relativement)transparent pour tes utilisateurs.

Choisis ton camp.

Note : même si la POO bénéficie d'un mot-clef spécifique à ce comportement, ce n'est pas un système propre à la POO. Par exemple si tu veux faire la même chose dans une bibliothèque en C (ou tout autre langage je pense), il suffit de ne pas définir une variable dans le fichier en-tête et de fournir par contre les fonctions qui permettent d'y accéder. Pour les mêmes raisons...

A ces excellentes considérations et explications, je rajouterai qu'il s'agit là de la notion d'encapsulation :
- protections des variables internes de la classe par rapport à la classe
(la classe "s'auto-gére", c'est elle qui définit les contraintes sur ses attributs)
- masquage de son fonctionnement interne (en tant qu'utilisateur de cette classe, on se fiche de savoir comment elle fait tel ou tel truc, l'important c'est qu'elle le fasse, certaines méthodes n'ont donc pas à être connues de l'extérieur)
 
L'idée c'est de pouvoir transformer  

en

Cette protection est faite en interne de la classe. L'utilisateur de la classe n'a pas à s'en préoccuper. Comme préciser par Elmoricq, si les contraintes viennent à changer, une simple modification de classe sera transparente pour le code déjà produit.
 
Et si on stocke en interne la temperature en Kelvin, l'extérieur n'a pas forcément à le savoir

pour abonder dans le sens de trevor, mettre tes variable en private te permet de changer ensuite l'implémentation de ta classe sans toucher à tes méthodes get et set...
 
si par ex tu as un getter qui doit renvoyer un int, la donnée dans la classe peut aussi bien être un int, du texte, un long, ce que tu veux...et ça l'utilisateur de ta classe a pas à le savoir, et surtout pour t'aider par la suite tu dois te laisser la liberté de modifier ton code le plus possible...parce que par exemple, changer la signature de qqc de public, c'est foutre le bordel dans le code de tous les gens qui utilisent ton code...et c'est pas apprécié

Un point important à tout ce qui a été dit. On peut faire son lot de getter/setter, définir les contraintes sur ses membres etc., mais ça n'explique pas réellement à quoi sert de définir ses membres privés.
En les mettant privés (et en fournissant tous les outils qui vont bien, bien entendu), on empêche ainsi les petits malins d'accéder à la structure interne de la classe et de venir foutre la merde !! (ouais, le même genre de petits malins qui viennent vous dire après "'tin t'as codé ta classe comme une merde, ça marche pas bien" )

tu peux tjs foutre la merde dans une classe si t'as envie...par réflection, tu peux la "dépuceler" sauvagement..
 
à l'époque où je faisais encore du dev, je m'étais codé un dumper d'état, tu lui passais une HTTPResponse, et il te dumpait tout ce qu'il y avait dedans au format HTML...et le code y allait gaiement, que tes membres soient privés ou pas...

Oh oui j'en suis sur Mais je parlais surtout en utilisation normale, sans contourner quoi que ce soit.

Ok, merci pour toutes vos explications  

Je comprends à peu près l'intérêt de private, mais c'est là que les ennuis commencent.
 
Si on le désire, Eclipse génère gentiment un getter et/ou un setter pour les variables private, afin qu'elles deviennent accessibles ailleurs.
C'est très bien.
 
L'ennui, c'est qu'il est difficile de trouver un exemple dans lequel ces variables sont utilisées. Ca oblige le débutant à essayer diverses syntaxes en espérant tomber sur la bonne.
 
Si dans la classe Machin j'écris :
 
public String maVariable = Bidule.getMaVariable();
 
 j'ai systématiquement une erreur "cannot make a static reference to the non-static method getMaVariable() from the type Bidule"
Pourtant, je jure sur l'honneur n'avoir pas cherché à faire la moindre référence statique, ni dans la classe Machin, ni dans la classe Bidule. J'ai soigneusement évité d'écrire ce mot.
 
Dans la classe Bidule, j'ai :
 
private String maVariable;
 
 public String getMaVariable() {
  return maVariable;
 }
 
Comme maVariable est utilisée par la méthode main(), je remarque que maVariable est sytématiquement soulignée, et le message d'erreur est du même genre :
 
La méthode main étant statique, je corrige la ligne suspecte dans Machin :
 
public static String maVariable = Bidule.getMaVariable();
 
Cette fois, l'erreur s'est étendue à Bidule. En revanche, dans la méthode main(), maVariable n'est plus soulignée.
 
Je modifie Bidule :
 
private static String maVariable;
 
 public static String getMaVariable() {
  return maVariable;
 }
 
J'ai toujours tout faux.  
Et là j'ai envie d'envoyer valser java...

Peu après, un peu calmé, je reviens sur mon problème.
 
Et là, j'ai l'idée de déplacer dans la méthode main() la ligne  
 
public String maVariable = Bidule.getMaVariable();  
 
Je l'avais mise avec les autres déclarations, comme public String toto; par exemple. (En fait initialement je créais maVariable dans Machin et dans Bidule, avant de me dire que ce serait aussi bien de récupérer la valorisation faite dans Bidule. J'ai modifié la ligne là où elle se trouvait, sot que de moi !)
Elle devient :
 
  Bidule maVar = new Bidule("aa", "bb" ); // Sauf erreur, "aa" et "bb" dépendent du constructeur
  String maVariable = maVar.getMaVariable();
 
Dans Bidule, j'ai remis sagement ceci :  
 
private String maVariable;  
 
 public String getMaVariable() {  
  return maVariable;  
 }
 
Et là, ça marche ! J'ai pas tout compris, vu que ça m'est venu tout seul, mais ça marche.

Absolument pas, ça n'a que peu de rapport avec le concept d'encapsulation.

Il y a deux concepts différents: l'encapsulation, qui groupe des objets et permet de définir un "intérieur" et un "extérieur", sans parler de contrôle d'accès, et "l'information hiding", qui vise à planquer e.g. les détails d'implémentation ou l'état interne soit complètement soit partiellement (en contrôllant simplement l'accès à ces données en lecture et/ou en écriture)

Si on veut un exemple plus précis, en Python on a plein d'encapsulation, mais très peu d'information hiding (c'est dans les principes même du langage)

J'ai une super idée: apprends à coder en java au lieu de faire des posts inutiles de 10 pieds de longs.
 
Cadeau: http://penserenjava.free.fr/

J'ai une idée encore plus géniale : rappelle-toi que tu n'as pas toujours su coder en java et que tu t'es souvent demandé d'où venaient tes erreurs.
 
Avec un soupçon de pédagogie, tu comprendras pourquoi certaines erreurs sont commises. Comprendre le pourquoi d'une erreur, c'est comprendre comment enseigner pour éviter cette erreur.
 
PS : Merci pour le cadeau, j'ai déjà ce lien dans mes favoris. Mais comme justement j'apprends à coder, j'ai encore pas mal de choses à assimiler. Alors soit j'apprends tout par coeur et j'espère devenir programmeur en écrivant mes premières lignes à la fin, soit je commence à me coltiner avec le langage dès le début, et forcément je me pose des questions qui m'aideront à comprendre les bonnes réponses.

Et quand je me posais cette question, j'allais voir la doc, ou le bouquin le plus proche, ou google.

Parce que tu codes plus avec les pieds qu'avec la tête et que tu n'as pas pris la peine d'acquérir les bases dans le langage que tu tentes d'utiliser, tu penses apparement que ton éditeur peut connaître le langage pour toi.

Je n'en vois pas l'intérêt, par contre lire tout le bouquin en faisant des tests au fur et à mesure des trucs que tu viens de lire, ça évitera à tout le monde de perdre du temps: à toi de te planter, de poser des questins à la con et de devoir en attendre les réponses, et aux membres du forum de devoir se demander si tes posts ont un quelconque intérêt.

Je suggère également http://forum.hardware.fr/hfr/Progr [...] 8709_1.htm

Déjà vu aussi ce lien, mais il n'est pas toujours évident d'y trouver ce qu'on y cherche.
 
Je recherche également beaucoup sur Google et dans mes bouquins, qu'imagines-tu ? Mais je n'y trouve pas toujours les réponses. Ca peut venir de questions mal posées. (Ca, c'est généralement l'expérience qui manque encore). Ou de questions "à la con", sauf que sur le moment on ignore qu'elles sont idiotes. Sinon je trouve surtout beaucoup de réponses tronquées, où seule la partie évidente est expliquée.
Quant aux tests, que je prends la peine de faire sans les recopier à partir du CD, soit ils sont trop faciles, soit ils nécessitent des connaissances un peu plus poussées que celles déjà acquises. Quand ils sont trop compliqués dès le départ, la solution n'apporte pas grand-chose. A la rigueur on la comprend, mais pour ce qui est de la refaire dans un contexte différent, c'est une autre paire de manches.
 
Que je code avec les pieds, c'est possible, j'ai encore beaucoup de lacunes alors faut faire avec et colmater dans l'urgence. L'essentiel c'est de coder et de se coltiner avec les problèmes, la tête finira bien par suivre. On apprend beaucoup de ses erreurs. A écouter les formateurs, tout paraît simple. En quelques lignes, ils obtiennent pile-poil le résultat qu'ils désiraient. On a tout compris, on est content. L'ennui, c'est qu'en essayant de refaire la même chose un peu plus tard, on s'aperçoit qu'ils ont oublié quelques explications indispensables au passage.
 
Un forum d'entraide, si c'est réservé aux experts, il serait bon de le préciser dès le départ. Quand je forme des gens dans ma spécialité, je ne m'attends pas à ce qu'ils sachent déjà tout et je ne trouve pas leurs questions idiotes. Elles m'aident à comprendre comment aborder avec eux le problème de la manière la plus efficace. Elles me rappellent que ce qui me paraît évident ne l'est peut-être que pour moi.
 
Pour finir, quand tu vois un fil où quelqu'un se demande quel est l'intérêt des variables private, tu dois bien te douter un peu que tu n'y auras pas affaire à des programmeurs chevronnés, et donc que tu risques fort d'y perdre ton temps. Moi, au contraire, je me doute que je vais y grapiller quelques infos utiles à mon niveau. Chacun joue dans sa cour.

 
Là je t'arrête, un forum n'est pas un centre de formation.
A croire qu'il faudrait afficher en gros en tête de toutes les pages du forum "VOUS N'ETES PAS SUR UN CENTRE DE FORMATION".
 
Donc quand tu débarque avec une question, on espère que tu a au moins pris le temps d'aborder les bases du langages que tu utilise. Ce qui ne semble pas être le cas puisque tu ne sait même pas pourquoi il te dit qu'il ne peut pas faire d'appel static sur ta méthode...
 
Cherche des choses du genre "différences entre class et objet", "instance", etc.

J'ai tendance à douter du fait qu'il n'y ait que "trop facile" et "trop dur", mais de toute façon:
 

• Ca n'empêche pas de faire des tests simples avec uniquement ce qui a déjà été couvert

• Si un exemple utilise des concepts qui ne sont pas encore connus, on regarde ce que ça donne, on essaie au moins d'identifier ce qui est connu, on tente potentiellement de deviner ce que fait le reste (en le notant sur un papier) et on continue à lire.

Quelle urgence, tu vas mourir si t'as pas une certif demain?

On apprend de ses erreurs quand les solutions sont non-triviales, quand l'erreur vient uniquement du fait de n'avoir pas appris le langage, le seul truc qu'on peut en apprendre c'est "faudrait ptet songer à apprendre ce que tu fais".

Il y a tout un monde entre "je balance des caractères au pif dans un fichier et ensuite je vais demander pourquoi ça marche pas" et "expert"..

Personne n'est ici pour te former, t'es tout seul garçon.

Pas nécessairement non, le concept de variable privée implique des concepts supérieurs d'information hiding, d'encapsulation, les "blocs" de base de la POO, si ce n'est que la base c'est néamoins une base intéressante et qui va au delà du fait de ne pas lire la doc, parce que la doc dit toujours comment, elle ne dit pas nécessairement pourquoi.

Qui parle de confondre avec un centre de formation ? Les questions, il est préférable de les poser à ceux qui savent répondre, et qui veulent bien prendre la peine d'y répondre sans le prendre de très haut. Y aurait-il une caste de gens qui savent et qui méprisent ceux qui essaient de savoir ?
Aborder les bases du langage, merci, c'est fait. Je l'ai constaté tout seul, le résultat n'est pas fameux, surtout après un mois de coupure intempestif. Ben tant pis, ça veut dire que je dois continuer à potasser les bouquins et essayer d'avancer quand même. Ce sera plus long que prévu, voilà tout, quitte à reprendre encore tout à zéro. Cent fois sur le métier...
J'ai des difficultés avec les objets, OK. Peut-être est-ce aussi un peu la faute de mes formateurs ou de la façon dont sont faits leurs cours, après tout ? Nous n'avons pas tous la même tournure d'esprit, la même méthode ne convient pas à tout le monde. Ca ne signifie pas que la matière serait réservée uniquement à ceux qui répondent bien à cette méthode-là.  
Moi, ce qui m'importe, c'est de comprendre d'où viennent mes erreurs. Enchaîner les commandes, les boucles, les tests, c'est ce que je sais le mieux faire (ou le moins mal). Si le problème vient de ce que je n'ai en réalité pas pigé les classes, les objets, les instances etc., ce qui fait la différence entre java et mes langages habituels donc, eh bien ! c'est une bonne piste à suivre. Si c'est suffisant pour débloquer tout le reste, le conseil sera utile. Et en retour j'insisterai dans l'évaluation de ma formation pour que ces points soient vus plus à fond en cours. Positivons.

Pourtant c'est pas compliqué, suffit de lire. Et la POO n'est pas propre à Java, le concepte restant globalement le même pour beaucoup de langages.
 
Quand tu créé une class, tu a définit une structure dans laquelle rien ne peut être utilisé directement, sauf ce qui est définit comme étant static et public, méthode et attribut. Auquel cas les appels doivent être effectués de la façon suivante :
NomDeMaClass.MaMehod();
 
Pour le reste, il faut créé une instance de ta class, que l'on appel objet. On pourrait la considérer comme une copie de ta class en mémoire. Pour cela il faut deux chose, une référence vers l'objet déclaré ainsi :
NomDeLaClass maClass;
 
On a donc une référence vers un objet de type NomDeLaClass. Mais on a toujours pas d'objet donc maClass pointe vers rien du tout, =null.
 
On doit donc créer une instance à l'aide de new ainsi :
maClass = new NomDeMaClass();
 
Voilà, c'est tout ce dont tu pouvais avoir besoin pour résoudre ton problème. Et ceux sont aussi des informations que l'on trouve dans de bons livres sur Java (Le miens étant "Programmer en Java" aux éditions Eyrolles) dans le début de l'apprentissage.

c'est tout ce que j'ai retenu d'intéressant du topic...

alors du coup en Python comment tu caches que ton implémentation pour être sur qu'un dev va pas se baser sur une propriété de ton algo qui sera peut etre pas stable dans le temps pour utiliser tes classes ?

PS : et pour Kiosseq, je plussois les autres : fais-toi le tutoriel de Sun pas à pas, ou lis bien le début de penser en java...concentre-toi quand ca parle de classe, de notion d'instance, de constructeur...regarde les premiers exemples, tu verras que ton code est une hérésie...
sachant que ce genre de poste de gens qui n'ont visiblement rien lu revient hyper souvent, tu comprendras l'irritation et le ton un peu sec qui t'ont acceuilli ici

Tu préfixes tout ce qui est interne avec un underscore ("_" ), ça dit simplement aux gens "ceci est un détail d'implémentation, utilisez le à vos risques et périls, si vous le faites et que ça pète c'est votre problème pas le mien".
 
De cette manière, 99% du temps les gens n'en auront pas besoin et utiliseront juste l'interface publiée, et le 1% restant (si il a besoin de faire quelque chose de spécifique, ou si ton API est mal définie/incomplète et que certaine tâches ne peuvent être menées à bien, ...), le mec qui aura absolument besoin de taper dans les données internes, il sera possible de le faire facilement sans passer par de l'introspection ou des macros dégueu type #define private public
 
Ce genre de trucs vient de l'un des principes/règles majeurs de Python: "we're all consenting adults". La communauté Python considère que tous les utilisateurs du langages sont des "adultes" vaccinés et consentants, et qu'ils ne vont pas faire des conneries juste pour pouvoir se plaindre. Elle (la communauté) n'est pas fan des principes "bondage & discipline"
 
Il est par ailleurs intéressant de voir que Smalltalk a des principes similaires: pas de concept de méthode privée en tant que tel (juste des catégories qui sont plus des indications que des règles), et si toutes les variables d'instances sont privées il est aisé d'y accéder via réflexion. Ca ne veut pas dire que c'est encouragé ou que c'est une bonne idée, mais s'il le faut absolument c'est là et disponible.

OK je vois...
 
en java tu peux aussi mais c'est lourdingue, et pas des plus rapide
 
mais c vrai que la philosophie du langage, c'est "laisse rien dépasser, montre que ce qui changera jamais"