OVH Cloud OVH Cloud

Visibilité des propriétés non spécifiées

10 réponses
Avatar
MiXAO
class Toto {
String str;
}

str est de quel type ? public ?
J'ai l'impression qu'elles sont publiques mais Eclipse utilise une
signalétique différente (triangle bleu).

10 réponses

Avatar
euler
MiXAO wrote:

class Toto {
String str;
}

str est de quel type ? public ?
J'ai l'impression qu'elles sont publiques mais Eclipse utilise une
signalétique différente (triangle bleu).


l'attribut par défaut est "package protected", c'est-à-dire que ces
attributs ou méthodes sont accessibles seulement aux autres classes du même
package

Avatar
MiXAO
euler wrote:
MiXAO wrote:


class Toto {
String str;
}

str est de quel type ? public ?
J'ai l'impression qu'elles sont publiques mais Eclipse utilise une
signalétique différente (triangle bleu).



l'attribut par défaut est "package protected", c'est-à-dire que ces
attributs ou méthodes sont accessibles seulement aux autres classes du même
package



Un grand merci.

MiXAO


Avatar
Pif
class Toto {
String str;
}

str est de quel type ? public ?
J'ai l'impression qu'elles sont publiques mais Eclipse utilise une
signalétique différente (triangle bleu).


de toute facon, un code clair se doit de spécifier les conditions
d'accessibilité des méthodes et attributs systématiquement... ;)

Avatar
Cléo
de toute facon, un code clair se doit de spécifier les conditions
d'accessibilité des méthodes et attributs systématiquement... ;)


Ben non, si tu veux que tes propriétés ou méthodes soient 'package
protected' tu ne spécifies rien ...
On n'est pas C++, et par conséquent tu dois t'adapter aux possibilités que
t'offre Java !


Amicalement.
--
Cléo.

Avatar
MiXAO
Cléo wrote:
de toute facon, un code clair se doit de spécifier les conditions
d'accessibilité des méthodes et attributs systématiquement... ;)



Ben non, si tu veux que tes propriétés ou méthodes soient 'package
protected' tu ne spécifies rien ...
On n'est pas C++, et par conséquent tu dois t'adapter aux possibilités que
t'offre Java !


Amicalement.


J'imagine que ça a dû être discuté des milliers de fois mais je trouve
un peu dommage a priori que les variables non spécifiées ne soient pas
plutôt en private qu'en package protected.
Comme je place toujours le plus possible de choses en private, je me
retrouve sans cesse en train de taper ce mot-clef à la déclaration de
mes propriétés.
Je me demande également dans quel cas on utilise concrètement le package
protected.

MiXAO


Avatar
Cléo
Je me demande également dans quel cas on utilise concrètement le package
protected.


C'est un façon différente de définir une relation de type 'friend' (C++)
entre plusieurs classes ...
Si tu te pose ce type de question, tu ne dois pas comprendre non plus
l'intérêt d'avoir plusieurs packages dans un projet ...


Amicalement
--
Cléo.

Avatar
Pif
le package permet d'organiser ses packets de facon logique
indépendamment des conditions d'héritages, par exemple pour mettre en
valeur l'aggregation ou autres...

je ne suis pas persuadé pour autant que le package doive jouer un role
dans l'accessibilité d'un membre de classe... c'est pas hyper propre...

mais de plus quelle est la différence entre "package protected" et
"package" ?
Avatar
Isammoc
Pif écrivait news:cmcron$2du$:

le package permet d'organiser ses packets de facon logique
indépendamment des conditions d'héritages, par exemple pour mettre en
valeur l'aggregation ou autres...

je ne suis pas persuadé pour autant que le package doive jouer un role
dans l'accessibilité d'un membre de classe... c'est pas hyper propre...

mais de plus quelle est la différence entre "package protected" et
"package" ?


bah... package protected = package + protected
donc tu peux y acceder aussi bien en package que par héritage...

--
Isammoc
qui essaye d'être logique

Avatar
Cléo
le package permet d'organiser ses packets de facon logique indépendamment
des conditions d'héritages, par exemple pour mettre en valeur
l'aggregation ou autres...


Pourquoi être aussi catégorique ?

--
Cléo.

Avatar
euler
Isammoc wrote:

Pif écrivait news:cmcron$2du$:

[...]


bah... package protected = package + protected
donc tu peux y acceder aussi bien en package que par héritage...



ah non, justement c'est là le problème : pas d'attribut de visibilité
signifie "package protected" donc seulement visible aux classes du même
package (sous-classes ou non)

Pour que les attributs soit visibles au classes du même package, ainsi
qu'aux sous-classes indépendamment de leur package, c'est l'attribut
protected qu'il faut utiliser. C'est pas très logique comme dénomination,
je suis d'accord, mais c'est comme ça