Question philosophique sur les "access level modifiers"

Bonsoir,


Je ne remet pas en cause l'existence des getters ou des setters (car ils ont une utilité dans le cas où on souhaiterait changer d'implémentation), mais je me demande parfois s'il ne serait pas utile de se débarrasser de ces 3 mot-clés : private, protected, public + de la visibilité package/default.

En effet la mécanique lors du développement est toujours la même : Mettre les attributs en privé, protégé si en compte se servir de ces attributs dans une classe Fille, et les méthodes en public (sauf si elle sert en interne). De plus, je trouve l'utilisation de la visibilité par défaut plus que douteuse en Java, elle n'a pas vraiment une raison d'être (bon même si on trouvera toujours une raison).

J'ai parfois l'impression que ces mots-clés, hérités du C++ (voir même d'un autre langage apparu avant celui-ci), encombrent inutilement le code :

• En C++ le but premier est peut-être d'indiquer qu'on cache l'implémentation du code... quand on développe en bas niveau pour des drivers et qu'on le vend à un client pourquoi pas, mais on sort du cadre des langages de haut niveau - décompilables - comme Java.
• Les langages tels que Python et Swift s'affranchissent ces mots-clés là; et puis un développeur peut s'il le désire utiliser exclusivement le mot-clé public en Java.

:fleche: Pensez-vous qu'il est vraiment utile (voir indispensable) d'avoir les access level modifiers dans un langage ?

PS: Lien de la documentation Oracle sur les Access Level Modifiers ici.

Citation:

---

Envoyé par Gugelhupf

Mettre les attributs en privé, protégé si en compte se servir de ces attributs dans une classe Fille, et les méthodes en public (sauf si elle sert en interne).

---

Ben, voilà. D'où utilité de public, protected et private. C'est le principe de l'encapsulation et s'il n'est pas indispensable, c'est une information utile aux utilisateurs d'une classe pour savoir si oui ou non, telle ou telle variable ou méthode les concerne.

Reste donc package-private : des variables et méthodes qui ne concernent que les classes du même package et pas les autres packages. Tu n'en parles pas. Il se trouve que dans la vraie vie, quand on programme proprement par contrat avec des interfaces, et une implémentation indépendante de ces interfaces, oui, c'est l'usage d'avoir plein de classes, variables et méthodes qui ne concernent que les classes qui font partie de cette implémentation, rangées par commodité dans le même package, et qui ne sont pas exposées à l'extérieur.

Indispensable, certainement pas. On peut tout à fait programmer en Python. D'ailleurs Python n'a même pas de typage statique. Le typage statique n'est pas indispensable, mais les situations où il permet de comprendre tout tout de suite, sont nombreuses. C'est pareil pour les visibilités.

Salut,

Citation:

---

Envoyé par thelvin

Ben, voilà. D'où utilité de public, protected et private. C'est le principe de l'encapsulation et s'il n'est pas indispensable, c'est une information utile aux utilisateurs d'une classe pour savoir si oui ou non, telle ou telle variable ou méthode les concerne.

---

Gros +1 je ne vois rien à jeter dans les visibilités public/protected/private qui ont toutes leurs utilités.


Le cas de "package-private" est un peu plus discutable, d'une part parce qu'il est ambigu (un mot-clef aurait été préférable), et d'autre part parce que son utilité est un peu restreinte.
Il serait souhaitable d'avoir une visibilité un peu plus large (globale au projet ou à la librairie) et non pas limité à un seul package (c'est envisagé dans le projet Jigsaw il me semble).


a++

Citation:

---

Envoyé par adiGuba

Gros +1 je ne vois rien à jeter dans les visibilités public/protected/private qui ont toutes leurs utilités.

---

Tout à fait d'accord.

Citation:

---

Envoyé par adiGuba

Le cas de "package-private" est un peu plus discutable, d'une part parce qu'il est ambigu (un mot-clef aurait été préférable), et d'autre part parce que son utilité est un peu restreinte.
Il serait souhaitable d'avoir une visibilité un peu plus large (globale au projet ou à la librairie) et non pas limité à un seul package (c'est envisagé dans le projet Jigsaw il me semble).

---

Je pense aussi que c'est une économie de mot clé pas très heureuse. Et je trouve l'utilité tres limitée. J'aurais préféré un concept plus proche du friend du c++ (mais qui ne permettrait pas d'acceder aux membres privés, juste ceux de la visibilité concernée). J'ai souvent des variables dans une classe qui sont necessaires à une autre pour une raison spécifique et je me retrouve obligé de mettre un getter public alors que je voudrais que seule cette classe y ait accès...
Mais concernant l'accessibilité, je trouve que le plus genant est que les membres protected ne sont pas réservées aux classes filles mais qu'elles soient accessibles aux classes du package...

je trouve le terme même de "access level modifier" ambigu.
oui l'encapsulation est nécessaire ne serait-ce que pour que le responsable du développement d'une classe dise clairement : "ça vous pouvez l'utiliser, ça laissez moi le droit de le changer plus tard sans que ça impacte votre code".
Curieusement j'ai constaté qu'un très grand nombre de programmeurs ne savaient pas répondre à cette question: "est ce que le code suivant se compile?"

Code:

---

1 2 3 4 5 6 7 8

public class Smurf { private int x;   public void copy(Smurf autre) { autre.x = this.x ; } }

---

la raison: confusion entre encapsulation et "droit d'accès" ... d'où l'ambiguité du terme.
Pour "protected" la situation est encore pire: une grande majorité de programmeurs Java que je rencontre ne savent pas ce que ça veut dire (et d'ailleurs beaucoup de bouquins sur le sujet poussent ce point sous le tapis en disant juste "protected veut dire accessible depuis les sous-classes" ... ce qui , à strictement parler, est faux!)

Citation:

---

Envoyé par hwoarang

Mais concernant l'accessibilité, je trouve que le plus genant est que les membres protected ne sont pas réservées aux classes filles mais qu'elles soient accessibles aux classes du package...

---

si on pose comme préalable: l'accès "protected" ne concerne pas l'aspect "métier" de la classe mais constitue un accès privilégié à un "mécanisme interne" de fonctionnement de la classe ... alors cette mesure peut se justifier.
Elle permet en plus de mieux expliquer le fonctionnement (compliqué) de protected.

Citation:

---

Envoyé par professeur shadoko

Elle permet en plus de mieux expliquer le fonctionnement (compliqué) de protected.

---

C'est vrai que j'ai parlé de protected mais ca pourrait etre un autre mot clé. L'idée, ce serait de laisser des attributs accessibles uniquement aux classes filles. D'ailleurs, c'est quelque chose qui m'a beaucoup surpris quand j'ai commencé à utiliser java que ce concept n'existe pas.

Je me rends compte que je n'ai pas parlé de la question de base : Est ce que les access modifiers sont utiles ?
Pour faire court : oui.
Pour faire long : Dans un projet avec plusieurs personnes, ca permet de donner une idée aux autres developpeurs de ce qu'on a voulu faire et de les aiguiller sur ce qu'ils ont le droit de faire ou pas. En ce qui me concerne, si pour une raison ou une autre, j'ai besoin de passer un attribut de privé à public, je me dis que je suis en train de casser quelque chose :aie: et d'utiliser une classe de la mauvais facon.
Maintenant, pour des developpements perso, c'est moins genant. Quand on code, perso, on a le droit de travailler comme un cochon :)
Mais bon, pour la maintenabilité, meme de son propre code, utiliser l'accessibilité permet de voir d'un coup d'oeil dans quelle optique a été faite telle ou telle chose, meme si on ne se rappelle plus de ce qu'on voulait à l'époque.