Discussion :

[domino313131]

Bonsoir,

je code depuis quelque temps en JAVA ( a un niveau debutant ), je fais quelques application de stockage et de manipulation de données en interecation avec une BDD.

et je ne vois toujours pas l'intérêt de l'utilisation du private à la place de public ? au contraire dans mon cas je trouve que c'est une perte de temps ?

si quelqu'un peut bien m'expliquer

mci

[andry.aime]

Bonsoir,

On utilise private pour une methode quand on ne l'utilise seulement que dans la même classe qui le possède. Même les classes filles ne pourrons pas y accéder. C'est pour cacher la comportement de la classe ou protéger des attributs.

A+.

[Ahamkara]

Hum... Je pense que le mieux serait d'aller lire les différents tutoriels qui se trouvent sur developpez.com.

http://java.developpez.com/cours/

Recherchez également ce qu'est la notion d'encapsulation, d'héritage et de polymorphisme et vous aurez votre réponse (en tout cas une grosse partie).

On pourrait écrire un livre pour répondre à votre question. Il en existe déjà tant.

[domino313131]

justement , '' proteger des attributs '' ok mais par rapport a quoi ? ou a qui ?

[andry.aime]

Bonjour,

Tu peux bien contrôler l'accès à l'attribut (affectation ou récupération de valeur).
Exemple tu as un attribut "mesure" dans une classe qui est en mètre. Tu le déclares en private et utilise deux methode public pour affecter sa valeur, l'un en mètre et l'autre en pied. La méthode qui a comme paramètre en pied fait la conversion sans que l'utilisateur de la classe s'en préoccupe et c'est transparent pour lui. Comme ça tu peux faire tes calculs sans se soucier des unités.

A+.

[JoeChip]

Protéger les attributs contre des modifications, plus tard, quand tu auras oublié comment ça se passe dans la classe (ce qui arrive quand elle est vraiment bien faite). Si par exemple tu as un attribut nommé "machin" dans ta classe, et que tu l'as oublié, tu vas peut-être plus tard utiliser une variable du même nom, en oubliant de la déclarer ; le compilateur ne signalera alors peut-être pas l'erreur. Un des objectifs de la recherche de nouveaux langages, c'est que le compilateur détecte un maximum d'erreurs, au lieu qu'elles sortent au run-time, de manière plus ou moins aléatoire.

Beaucoup des avantages de la POO n'apparaissent pas immédiatement. Ce qui a l'air d'une perte de temps (et qui l'est même peut-être), quand le programme est petit, devient un avantage inestimable en termes de fiabilité lors de la maintenance : un autre grand problème en programmation, c'est, pour la maintenance de gros programmes, d'éviter d'introduire des nouveaux bugs à chaque modif, y compris à chaque suppression de bug, ce qui fait qu'à partir d'une certaine taille de programme et de nombre de modifs, il devient impossible de diminuer le nombre de bugs, ce qui explique que certains programmes deviennent immodifiables et doivent être entièrement réécrits.

Imaginez par exemple un programme de 5000 lignes, où toutes les variables sont globales et non déclarées (cas du basic interprété d'origine) : à chaque modif, si on ajoute un nom de variable, la probabilité est énorme que ce nom existe déjà, et donc qu'on aie une grosse probabilité de créer un nouveau bug, qui ne se révèlera peut-être que de temps en temps... En plus si je fais une faute de frappe dans le nom de la variable, rien ne va me le signaler...etc

[thelvin]

Une autre manière de le voir est ceci :

Les débutant pensent souvent comme s'il n'y avait qu'un seul programmeur qui travaille tout seul sur le programme à réaliser. Dans leur tête, ce programmeur étant tout seul, il connaît tout du programme, et doit donc avoir le pouvoir absolu dans tous les aspects du programme.

Mais c'est faux. La classe String, par exemple : elle est là mais c'est pas le débutant qui l'a faite, c'est les gens de Java qui l'ont faite. Pareil pour toute la bibliothèque de base. Et il existe plein de bibliothèques, qui ont été faites par d'autres gens et qu'on peut utiliser.
Dans toutes ces classes, il y a des attributs et des méthodes servent à être appelés par le programme principal, qui est là à disposition de tous les programmeurs de toutes les classes du monde.
Et il y a aussi plein d'attributs qui servent uniquement à la classe elle-même et qui ne concerne pas le reste du monde. Si quelqu'un d'autre pouvait changer leur valeur, ça casserait tout. Donc il faut empêcher que d'autres changent la valeur. Et sa valeur ne regarde pas les autres classes : si elles essayaient de la lire et d'en tirer quelque chose, elles se tromperaient. Parce qu'elles ne savent pas à quoi sert cet attribut, qu'elles ne sont pas aptes à s'en servir, et que ça ne les regarde pas. Donc, pour éviter ça, elles ne doivent pas pouvoir le lire.

Ce qui concerne toutes les classes du monde, est public. Ce qui ne concerne que la classe en cours, est private. C'est tout.

C'est aussi utile quand on travaille sur un gros projet, pour rester organisé. Si on sépare bien ce qui concerne toutes les classes de ce qui ne concerne que la classe en cours, la programmation est plus confortable, moins complexe.

Ça c'est l'explication pour les débutants. En réalité, cela est aussi très important pour que fonctionnent l'encapsulation et le polymorphisme, utilisés tout le temps en POO.

[Rei Ichido]

justement , '' proteger des attributs '' ok mais par rapport a quoi ? ou a qui ?

Par rapport aux développeurs.
Quand tu es seul sur un petit projet, tu peux penser avoir la maîtrise de ton périmètre ; c'est déjà rapidement faux (si ton projet grandis), et d'autant plus faux quand tu es plus de un.

L'exemple souvent utilisé, c'est une gestion de compte bancaire. Tu as un attribut solde, mais tu ne veux pas laisser n'importe quelle classe pouvoir le modifier comme ça. Les deux seules façon de le modifier devraient être credit(int somme), et debit(int somme), qui effectueront probablement des contrôles (enfin, surtout debit ), et lanceront d'autres méthodes si besoin est (genre, solde débiteur mais dans la limite autorisée => agios).

N'importe quel programmeur qui implémente un nouveau module n'aura pas à se soucier du détail, et ne pourra pas faire n'importe quoi - s'il voyait solde, il aurait tendance à faire solde = solde + somme, alors que là il sera obligé de passer par credit(somme).

[billynirvana]

Imaginons que tu as une classe Jeu qui contient ces deux propriétés:
grille[][] et solution[][].

Il est clair que tu ne vas mettre en public la variable solution.