Salut,

Je connais correctement le C++, mais j'ai voulu apprendre un peu le Java sur ce site via le cours de cysboy.
J'en suis à l'héritage, pour l'instant, pas de réelle différence niveau philosophie entre Java et C++. Seulement, il y'a quelque chose qui m'échappe: le mot-clef protected.
J'ai très bien compris le concept, en fait, d'après le cours, c'est comme en C++, du moins d'après le cours. Je cite:

Citation : Cysboy

C'est ici que je vais vous apprendre un nouveau mot clé : protected.
En remplaçant la déclaration des variables et des méthodes privées de la classe Ville en protected, cela aura pour effet de toujours protéger l'accès à celles-ci depuis du code utilisant un objet Ville ; mais cela permet aux classes qui héritent de cette dernière d'y avoir accès !

Or, si j'essaye simplement de mettre un attribut en accès protected, je peux encore y avoir accès dans le main (contrairement au C++), ce qui lui enlève tout intérêt.
Le main est-il une exception au mot-clef protected ?

Merci.

Il me semble que le package y a accès aussi ...à vérifier

Citation

Il me semble que le package y a accès aussi ...à vérifier

En effet. Toutes les classes qui sont dans le même package ont accès aux variables protected.

Pas du tout

Si tu déclares ta variable private, protected, ou même public, si ta méthode main se situe dans la classe où sont déclarées les variables, elle pourra accéder à tous ses membres de classe (ie les variables static), ou à tous ses membres d'instance (par l'intermédiaire d'un objet créé dans le main bien sûr).

En général on place la méthode main dans une classe à part, la raison vient sûrement de là.

Il y'a beaucoup de critiques sur ce mot-clef, et certains préfèrent même le bannir complètement de leur code. J'ignore leur raison même si j'ai ma petite idée là-dessus.
Personnellement je code totalement sans ce mot de toute manière, je préfère de loin les getter-setter, mais moi c'est par soucis de clarté.

Qu'est-ce que vous en pensez vous autres ?

Pour moi la classe du main est une classe particulière , jamais je le mettrais dans une autre classe.

A part ça , chaque mot clé à un degré de visibilité particulier ,il suffit de bien choisir celui qu'il nous faut en fonction des cas.

Vous pouvez dire aussi que c'est l'un des incovéniants de la POO ....je vois pas vraiment l'utilité des ces mots-clef.Sachant que dans la POO il y a le Créateur et le User , et dans la majorité des cas le createur c'est lui même le user de ça creation donc vraiment je trouve pas d'interêt .

Citation : elmh

Pas du tout

Si tu déclares ta variable private, protected, ou même public, si ta méthode main se situe dans la classe où sont déclarées les variables, elle pourra accéder à tous ses membres de classe (ie les variables static), ou à tous ses membres d'instance (par l'intermédiaire d'un objet créé dans le main bien sûr).

En général on place la méthode main dans une classe à part, la raison vient sûrement de là.

Si si

J'ai testé avec une classe contenant le main, et une autre classe qui contient des attributs en accès protected.

Depuis le main, après avoir instancié un objet O1, je peux accéder sans soucis aux attributs protected de O1.
Après quelques recherches google sur "package", il semble que QuentinC 2 et XzZy ont raison, on peut accéder aux attributs protected dans les classes filles (logique, c'est son but premier), et dans le package "actuel" (ce que je trouve complètement absurde, mais bon).

En tout cas, en C++, ce mot-clef est hyper-pratique. Je l'utilise très souvent. Je pense qu'il est autant utile en Java

Citation : Waht?

Sachant que dans la POO il y a le Créateur et le User , et dans la majorité des cas le createur c'est lui même le user de ça creation donc vraiment je trouve pas d'interêt .

Ah bon ? Dans la majorité des cas ? Et toutes les bibliothèques externes (STL, SL en C++ par exemple, ou biblio. graphique, etc...), enfin "packages" ? Ce n'est pas moi qui les ai créés, et je les utilise énormément, autant que mes classes perso.

Oui je ne contredis pas les réponses données, le site a planté et mon message a été validé plus d'une heure après.

Mon "pas du tout" c'était en référence à ton "Le main est-il une exception au mot-clef protected ?".

Et oui tu peux accéder à une variable protected d'un objet sans passer par son getter (c'est pour ça que créer un getter d'une variable protected est presque inutile).

Citation

[...] et dans le package "actuel" (ce que je trouve complètement absurde, mais bon).

C'est un point effectivement très discutable et discuté du langage. Je n'ai encore jamais vu concrètement où ce genre d'accès était indispensable, mais si Sun l'a mis, c'est qu'il doit y avoir une utilité.

Question de simplicité, je pense.

Les getters/setters sont faits pour que le développeur de la classe contrôle ses données. Mais en général, un package est un tout, il peut y avoir un couplage fort. Du coup, qu'une classe accède directement aux attributs d'une autre classe du même package, ça n'est pas dramatique.

C'est une philosophie qui se discute, mais il me semble que c'est la raison d'être du protected.

Citation

Les getters/setters sont faits pour que le développeur de la classe contrôle ses données. Mais en général, un package est un tout, il peut y avoir un couplage
fort. Du coup, qu'une classe accède directement aux attributs d'une autre classe du même package, ça n'est pas dramatique.

Ah, vu comme ça c'est pas faux.

Si le couplage est vraiment très fort autant en faire une classe interne si elle n'a pas une utilité autre dans le programme.

Sinon généralement tout se fait en private avec getters et setters c'est plus propre et plus contrôlable.

Tu peux avoir un package avec de fortes dépendances entre les classes sans pour autant n'avoir de dépendances qu'au sein du package en question. Du coup, avoir plusieurs classes à fournir à l'extérieur justifie largement qu'elles soient séparées (Et pas toutes classes internes d'une même classe) J'ai pas vraiment d'exemples en tête, utilisant moi-même assez peu le protected (Enfin, seulement pour l'héritage quoi ; et encore, pas toujours), mais ça ne me parait pas aberrant.

Après, comme je disais, c'est une explication (Fournie par mon prof' de POO en L3, ça vaut ce que ça vaut, ce n'est pas forcément la raison officielle), pas une prise de position. On peut être pour ou contre, mais ça changera pas grand chose au "pourquoi c'est comme ça ?"

Okay merci à tous, de tout façon j'ai eu réponse à ma question

Je verrais avec plus d'expérience si l'utilité de protected en Java reste limitée ou non.