Discussion :

[FCDB]

Salut, je suis en train de préparer un graphique UML et je me rend compte que je ne rend public aucun attribut de classe ( comme c'est le cas dans tous les codes sources que j'ai eu l'ocasion de lire ). Si je veux qu'un attribut soit accessible à l'extérieur de la classe j'implémente les méthodes public get et/ou set...
Existe-t-il une situation où l'utilisation du modificateur d'acces public pour un attribut se justifie? Je demande ça parce que je n'en vois aucun; et dans cette optique, java devrait empêcher de déclarer un attribut public, non?

[Gfx]

Pose-toi plutôt la question "pourquoi ne déclare-t'on pas les attributs publics". En pratique rien ne te l'interdit et je ne vois pas pourquoi cela devrait être le cas. Entre nous si tu écris ça c'est comme si tu utilisais un attribut public :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
private int membre;
 
public int getMembre() {
  return membre;
}
 
public int setMembre(int membre) {
  this.membre = membre;
}

Si tu fais des choses comme ça, tu ne fais qu'un bête "public int membre" camouflé.

Dans certains cas un attribut public peut se révéler plus facile à utiliser du que des accesseurs et mutateurs. Historiquement les attributs publiques sont utilisés à certains endroits d'AWT pour améliorer les performances. C'était avant que les compilateurs Java sachent inliner et surtout avant les JIT vraiment performants.

[FCDB]

Je suis d'accord mais je pense que cette façon de faire permet après coup un plus grand contrôle.

On peut vouloir autoriser la lecture et interdire l'écriture, dans ce cas on ne crée pas la méthode set. On peut rajouter un contrôle de la valeur rentrée dans le set... On peut aussi imaginer un set() qui s'applique à quelque chose de plus complexe qu'à un simple Int ou String.

Je trouve ça : objectA.setName("newName") ;
plus lisible que : objectA.name = "newName" ;
C'est sûrement une question d'habitude.

"pourquoi ne déclare-t'on pas les attributs publics"

Je crois que c'est par sécurité.

[Gfx]

Bien sûr qu'on peut aller plus loin que mon exemple mais dans beaucoup trop de cas c'est ce qui est fait. Quant à la sécurité c'est pour protéger les données... mais de qui ou de quoi ? En as-tu vraiment besoin si tu ne publies pas l'API ou que tu es le seul développeur ? Es-tu protégé par tes mutateurs ? Pour en revenir à la sécurité lis donc cela au sujet des attributs privés : http://www.progx.org/index.php?section=replies&newsid=572

[FCDB]

Sympa l'astuce, avec un exemple très parlant en plus .

Je pense que même si on code seul il faut le faire dans l'optique qu'il pourra être modifié par quelqu'un d'autre plus tard. Par nous-même un an après aussi d'ailleur.

Merci pour tes réponses

[Gfx]

Certes mais cela doit être fait intelligemment. D'autant plus que l'abus d'accesseurs et mutateurs est souvent signe d'un mauvais design objet

[Hephaistos007]

Les modificateurs de visibilité sont là pour indiquer quels traitements (dans notre cas : les méthodes) vont être exportés, c'est à dire disponibles à travers une interface (à ne pas confondre avec le mot clé interface Java).
Cette interface est implicite en Java, alors qu'elle peut être explicite dans d'autres langages, comme l'Ocaml par exemple.

Cette notion d'interface est tellement importante qu'elle est considérée comme entité de première classe (first class citizen pour les intimes) dans le paradigme des composants. Tout cela a été conçu dans une optique de réutilisation (pierre angulaire du paradigme composant) et donc de distribution. Ainsi, comme le remarque très justement Gfx, lorsqu'il n'y a pas de distribution d'objet (les objets sont développés et utilisés par toi uniquement), les modificateurs de visibilité n'ont aucun n'intêret si ce n'est ne respecter une "charte du bon programmeur", pour le fun quoi !.

L'existence des modificateurs de visibilioté est donc liée à l'une des motivations initiales du paradigme objet : la distribution/réutilisation.