Private obligatoire pour l'encapsulation ?

Bonjour a tous,

J'ai deux petites questions à poser sur l'encapsulation...

Doit on obligatoirement mettre tout les attributs, objets etc de la classe en privee pour respecter l'encapsulation?

ex;

Code:

---

1 2 3 4 5 6 7 8 9 10

Class Exemple extends JFrame { private int x; /*private?*/ JPanel pan;   Exemple() { this.add(panel); } }

---

Le fait de ne pas declarer l'objet panel en private 'brise' les regle de l'encapsulation?

Et aussi, j'ai du mal a voir l'interet lorsque l'on code une appplication (pour coder une lib je comprends bien, etre sur que lutilisateur ne puisse pas avoir acces a certain attributs) car la seul personne a avoir acces au attributs sera moi? donc a quoi sert de rendre tout private??

Merci par avance

Bonne journee

Dom

Bonjour,

Citation:

---

Doit on obligatoirement mettre tout les attributs, objets etc de la classe en privee pour respecter l'encapsulation?

---

Oui, sauf si tu conçois une classe susceptible d'être sous-classée par d'autres développeurs bien sûr, auquel cas tu mettras l'attribut "protected". Mais tu dois, pour chaque attribut, réfléchir s'il doit être privé ou protégé.

De manière générale, oui, oui, et re-oui, il faut encapsuler au maximum. Le secret d'une bonne classe est d'avoir des entrées et des sorties bien définies, que celles-ci soient contrôlées, et que le reste soit blindé.

Il n'est jamais bon de croire qu'on ne code que pour soi. Même si cela s'avère être vrai au bout du compte, tu te rends de toute façon un grand service en partant du principe que ce n'est pas le cas, car tu te protèges alors de tes propres erreurs. Si tu conçois une classe en laissant toutes les portes ouvertes et en te disant "De toute façon, je suis seul à la toucher et je sais ce que je dois faire", tu vas dans le mur, car tu risques de commettre toutes les erreurs qui ont justement motivé l'invention du paradigme objet.

Il y a une abondante littérature à ce sujet, mais sache que le principe d'encapsulation ne sert pas seulement à protéger les accès vis-à-vis des "autres développeurs". Il sert d'abord à te forcer à bien concevoir les choses de manière à réduire la complexité. Plus une classe expose ses attributs, plus elle est complexe, car il est possible de modifier son état de n'importe où.

Le principe de la POO est de découper le problème à résoudre en sous-parties et de les résoudre individuellement, afin d'avoir le moins de choses à penser en même temps. Une classe est en quelque sorte une unité du problème, et si tu n'encapsules pas, alors tu ne cloisonnes pas les différentes parties de ton problème, et la complexité de ton programme va augmenter.

Plus les choses sont cloisonnées, plus elles sont faciles à tester, et moins il est possible de faire des erreurs. J'aime bien dire qu'une classe est une entité inviolable qui a une responsabilité bien définie et qui, d'une part, ne doit pas en dévier, et d'autre part, ne peut pas en dévier. Tu obtiens ça grâce à une bonne encapsulation. Si tu laisses des attributs publics, donc des accès béants, tu permets à quelqu'un (et donc surtout à toi) de "violer" ta classe...

N'oublie pas que ce n'est pas tellement des autres que du dois protéger ton code, c'est surtout de toi. Le fait de programmer en partant du principe que ton code ne sera pas utilisé/terminé par toi (même si ce n'est pas vrai au final) te rendra de grands services ;).

J'ajoute encore une chose : mon expérience personnelle. Je travaille depuis deux ans sur du code Java écrit par des gens venant du monde C, et qui en plus étaient débutants en C. En gros, les classes étaient des immenses fourre-tout, où en plus, tout était public.
En deux ans, nous avons remanié successivement beaucoup de choses, et nous avons considérablement amélioré le code, mais il reste des choses qui ne pourront pas changer sans repasser par l'étape "conception". Encore aujourd'hui, notre produit n'est guère stable, et on sait qu'on n'obtiendra pas la stabilité dont on rêve tant qu'on n'aura pas repris à zéro. Il faudrait juste qu'on nous laisse le temps de le faire...

Bien sûr qu'il est possible d'être propre sans encapsuler complètement. Le code de Linux en est un bon exemple je crois. C'est du C, on y fait usage de variables globales il me semble, mais n'oublions pas que les modifications apportées sont soumises au contrôle sévère des lieutenants de Linus Torvalds.
Là, tu es en Java, tu disposes donc d'un langage qui te permet nativement d'encapsuler correctement. Le fait de chercher à le faire te force à mener une réflexion saine sur l'utilisation de tes attributs. Pourquoi s'en priver ?...

Ha super, merci beaucoup pour cette reponse!!!

Donc on peut dire que l'encapsulation est plutot une 'methode' de travail qui vise a rendre notre code plus 'solide'...

Vu sous cet angle, je trouve cela plus logique, car la seul defenition que j'avais etait de rendre l'acces au attributs impossible pour l'utilisateur, ce qui au final, n'etait pas vraiment neccessaire...

Encore merci pour cet explication :)

Bonne journee

Dom

ps; Juste histoire d'etre sur, une derniere question :)

Est ce correct d'imager l'encapsulation par cette exemple:

1ere classe :

Code:

---

1 2 3 4 5 6 7 8 9 10

class Porte { private boolean isLock;   Porte() { isLock = true; } }

---

et une deuxieme classe :

Code:

---

1 2 3 4 5 6 7 8 9

class Voleur { Voleur() { Porte pt = new Porte(); pt.isLock = false /* serais donc possible sans l'encapsulation, et serait illogique...*/ } }

---

Je vien juste de voir ton 2ieme post apres t'avoir repondu...

Une chose me semble bizare ->

Citation:

---

Le code de Linux en est un bon exemple je crois

---

Je croyais pourtant que la notion d'encapsulation etait propre a la POO, donc ce serait normal que Linux (code en C, donc sans la POO) n'encapsule pas ces attribut (variable je crois lorsque ce n'est pas de la POO? *plus trop sur*) non?

Est ce que je me trompe?

Effectivement, ton petit exemple illustre un danger de ne pas encapsuler. Je vois trois objectifs principaux de l'encapsulation :

• cacher les détails d'implémentation aux développeurs "clients"
• réduire les erreurs possibles en protégeant les attributs, et de manière générale le fonctionnement interne d'une classe, afin d'éviter de "casser" son fonctionnement
• réduire la complexité en limitant les dépendances entre les classes à des accès prédéfinis et surtout, réfléchis.

Concernant le dernier point, cela signifie en gros que, si tout est public, quand tu as besoin d'accéder à un attribut, tu le fais, sans réfléchir. Au final, tu peux obtenir ce qu'on appelle du code "spaghetti" et qui est un cauchemar à maintenir. Alors que si tu encapsules, tu dois te poser des questions à propos des accès que tu veux ouvrir aux autres classes. Cela signifie aussi : ne pas se contenter de mettre les attributs privés et leur mettre à chacun un getter/setter sans réfléchir, car cela reviendrait (presque) au même.

Concernant mon exemple sur Linux, je voulais montrer qu'il était possible d'écrire du code propre sans encapsulation en disant ça :

Citation:

---

Bien sûr qu'il est possible d'être propre sans encapsuler complètement

---

Car justement, Linux est écrit en C, donc sans POO, mais on peut le qualifier de "propre" je pense, car il ne serait pas devenu ce qu'il est aujourd'hui sinon ;). Mais je voulais surtout dire que si tu programmes en Java, qui supporte nativement les mécanismes de la POO, il ne faut pas se priver de les utiliser.

Voilà, content d'avoir pu t'aider !

Merci beaucoup pour ces reponses claires et precises!

C'est exactement ce que je voulais savoir :)

Bonne journee

Dom