Question de debutant venant du C++

"Chewee" <padmail> wrote in message news:<40b3370f$0$26908$626a14ce@news.free.fr>...

Bonjour à tous,

captainpaf wrote:

Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil pas
forcément). Tu mets un getter public mais au lieu de retourner une
référence vers l'attribut de l'objet il retourne une nouvelle
référence identique (voir clone())à celle de l'attribut.
Ainsi les modifications ne seront pas reportées au niveau de l'objet
de départ.
Et pour les setter, il suffit de jouer sur la visibilité.

Ta méthode marche, mais là c'est carrément sous-optimal.
Je ne vais pas dupliquer tout mon objet à chaque fois que j'utilise un
accesseur...

Moi je dirais que cette méthode (la recopie défensive) ne fait pas
la même chose que le mot clé const placé après la déclaration de la
méthode, dans un cas tu protège les données membre de l'objet appellé
(const) dans l'autre tu protège celle de l'objet retourné (recopie)...

En fait la recopie défensive remplacerait plutôt le const appliqué
au type de retour (donc devant la décalration). Ou alors quelque chose
m'échappe...

Je crois que l'équivalent de cet usage de const n'éxiste pas en
java. ça doit pouvoir ce faire à coup d'héritage et/ou de classes
membres mais ça n'est pas forcément souhaitable...

En java on ne programmme pas comme en C++ il y a des bonnes
pratiques différentes, en particulier sur les questions d'accès
(visibilité, final, static...).

Je te recommande vivement la lecture de "Java Efficace" (Vuibert)
qui ne fait que 170 pages (et, de mémoire, 27€) ça te donne vraiment
une idée concrète de comment programmer en java... Sinon Java In a
Nutshell (O'Reilly) est bien mais plus classique: il explique en
détail les fonctionnalités de chaque mot clé, mais il ne met pas
l'accent sur comment les utiliser pour bien programmer en java...

Si ton appli est déjà en C++ et que tu la porte tu peux continuer
comme ça, mais rapidement tu vas devoir comprendre ce qu'est java pour
bien programmer. Si tu fais une nouvelle appli, oublis C++. Tu peux
garder pratiquement toute ta conception objet (en gros ce qui s'écrit
en UML), mais pour le reste il faut penser directement en Java. C'est
un peu comme les langues étrangère, penser en français et traduire en
anglais ne donne pas le même résultat que penser directement en
anglais et l'écrire... Mais ça demande plus de compétences...

Au départ j'ai cherché à "traduire" du C++ en java et j'ai trouvé
que Java était vraiment limité. J'ai changé d'avis en apprenant à
penser en Java, notamment en lisant "Java Efficace". ça m'a permit
d'éradiquer pas mal de lourdeur dans mon code, en particulier grâce au
classe anonymes et aux interfaces utilisé correctement...
C'est marrant parce que j'ai eu le problème inverse en revenant
après un an de Java à C++... "Putain comment on fait une classe
anonyme en C++!!!" :-)

Il faut habituer son cerveau à penser dans l'un ou l'autre des
langages...

Bienvenue à bord...

dans un cas tu protège les données membre de l'objet appellé
(const) dans l'autre tu protège celle de l'objet retourné (recopie)...

On peut toujours retourner une référence const plutôt qu'une copie. Ca évite
que l'objet soit copié et qu'il puisse être modifié, l'accesseur y perdait
tout son intérêt.

JM

Vince44 wrote:

"Chewee" <padmail> wrote in message
news:<40b3370f$0$26908$626a14ce@news.free.fr>...

Bonjour à tous,

captainpaf wrote:

Tu peux bien sûr faire ce que tu désires (mais je ne te le conseil
pas forcément). Tu mets un getter public mais au lieu de retourner
une
référence vers l'attribut de l'objet il retourne une nouvelle
référence identique (voir clone())à celle de l'attribut.
Ainsi les modifications ne seront pas reportées au niveau de l'objet
de départ.
Et pour les setter, il suffit de jouer sur la visibilité.

Ta méthode marche, mais là c'est carrément sous-optimal.
Je ne vais pas dupliquer tout mon objet à chaque fois que j'utilise
un accesseur...

Moi je dirais que cette méthode (la recopie défensive) ne fait pas
la même chose que le mot clé const placé après la déclaration de la
méthode, dans un cas tu protège les données membre de l'objet appellé
(const) dans l'autre tu protège celle de l'objet retourné (recopie)...

En fait la recopie défensive remplacerait plutôt le const appliqué
au type de retour (donc devant la décalration). Ou alors quelque chose
m'échappe...

Je crois que l'équivalent de cet usage de const n'éxiste pas en
java. ça doit pouvoir ce faire à coup d'héritage et/ou de classes
membres mais ça n'est pas forcément souhaitable...

En java on ne programmme pas comme en C++ il y a des bonnes
pratiques différentes, en particulier sur les questions d'accès
(visibilité, final, static...).

Je te recommande vivement la lecture de "Java Efficace" (Vuibert)
qui ne fait que 170 pages (et, de mémoire, 27?) ça te donne vraiment
une idée concrète de comment programmer en java... Sinon Java In a
Nutshell (O'Reilly) est bien mais plus classique: il explique en
détail les fonctionnalités de chaque mot clé, mais il ne met pas
l'accent sur comment les utiliser pour bien programmer en java...

Si ton appli est déjà en C++ et que tu la porte tu peux continuer
comme ça, mais rapidement tu vas devoir comprendre ce qu'est java pour
bien programmer. Si tu fais une nouvelle appli, oublis C++. Tu peux
garder pratiquement toute ta conception objet (en gros ce qui s'écrit
en UML), mais pour le reste il faut penser directement en Java. C'est
un peu comme les langues étrangère, penser en français et traduire en
anglais ne donne pas le même résultat que penser directement en
anglais et l'écrire... Mais ça demande plus de compétences...

Au départ j'ai cherché à "traduire" du C++ en java et j'ai trouvé
que Java était vraiment limité. J'ai changé d'avis en apprenant à
penser en Java, notamment en lisant "Java Efficace". ça m'a permit
d'éradiquer pas mal de lourdeur dans mon code, en particulier grâce au
classe anonymes et aux interfaces utilisé correctement...
C'est marrant parce que j'ai eu le problème inverse en revenant
après un an de Java à C++... "Putain comment on fait une classe
anonyme en C++!!!" :-)

Il faut habituer son cerveau à penser dans l'un ou l'autre des
langages...

Bienvenue à bord...

Merci pour cette réponse et ces conseils.
Je ne suis pas du tout en train de porter une appli C++ en java, c'est juste
que je découvre complètement java et comme je connais bien le C++ (5 ans
d'expérience), je me pose certaines questions sur les différences entre les
deux languages (très proches quand même).
Bien entendu, je suis conscient que la traduction d'un language vers l'autre
n'est pas une très bonne idée, ce n'est pas du tout mon but.
Je pense que je lirais "Java Efficace" à l'avenir (merci pour le tuyau) mais
je n'en suis pas encore à ce point. Pour le moment, j'apprends vraiment les
bases du language (et à titre purement personnel).

Je pense que je reviendrais vers vous de temps en temps quand j'aurais
d'autres questions, mais je ne pourrais m'empècher de faire le parallèle

avec le C++, quitte à déplaire à certains...

Aucun problème j'en viens aussi :).

Par contre tu risques d'être surpris car il faut avoir de bonnes bases en
POO pour comprendre Java. Connaître seulement C++ ne permet pas de faire la
transition, tu peux te reposer sur certains acquis mais le système de pensée
n'est plus le même. De plus je connais très peu de développeurs C++ qui font
du pur C++, généralement on se retrouve avec un mélange de C et de C++, car
C++ nous laisse le choix. Et souvent un développeur C++ a un background de
développeur C alors on peut pas faire pire, c'est mon cas ^^.

Je redécouvre Java après quelques années d'hibernation, enfin je ne suis pas
encore certain de passer à Java à cause de problèmes de performances, je
viens du jeu vidéo j'ai ça dans le sang :).

Pour les surprises Java tu te retrouves sans enum par exemple mais il existe
des motifs (design patterns) pour résoudre tous les problèmes. Si tu
cherches « java enum design pattern » sur Google, tu vas être servi.

Pour ce problème d'accesseurs (get/set) j'avais lu quelques articles qui
proposaient des solutions alternatives mais ma mémoire n'a pas retenu ce
qu'elles étaient. Notamment que les accesseurs ne servaient rien sinon à «
wrapper » les propriétés d'un objet dans une méthode. Au final c'est un peu
ça mais on limite les effets de bord comme tu l'as souligné, à l'époque je
crois que c'était une belle guerre alors j'ai rapidement laissé tomber sans
chercher à trop comprendre, je suis peut-être passer à côté de quelque
chose. Quelqu'un sait de quoi je parle ? :p.

JM

Jean-Marc Molina wrote:

Je pense que je reviendrais vers vous de temps en temps quand
j'aurais
d'autres questions, mais je ne pourrais m'empècher de faire le

parallèle avec le C++, quitte à déplaire à certains...

Aucun problème j'en viens aussi :).

Par contre tu risques d'être surpris car il faut avoir de bonnes
bases en POO pour comprendre Java. Connaître seulement C++ ne permet
pas de faire la transition, tu peux te reposer sur certains acquis
mais le système de pensée n'est plus le même. De plus je connais très
peu de développeurs C++ qui font du pur C++, généralement on se
retrouve avec un mélange de C et de C++, car C++ nous laisse le
choix. Et souvent un développeur C++ a un background de développeur C
alors on peut pas faire pire, c'est mon cas ^^.

Merci du conseil...
Je pense avoir un background POO suffisant pour franchir le pas du java...
Je verrais bien à l'usage.

Je redécouvre Java après quelques années d'hibernation, enfin je ne
suis pas encore certain de passer à Java à cause de problèmes de
performances, je viens du jeu vidéo j'ai ça dans le sang :).

Ca c'est rigolo, je viens aussi du jeu vidéo ;-)

"Jean-Marc Molina" <jmmolina_pasdepourriel@free.fr> wrote in message news:<40b4890e$0$32159$626a14ce@news.free.fr>...

Pour les surprises Java tu te retrouves sans enum par exemple mais il existe
des motifs (design patterns) pour résoudre tous les problèmes. Si tu
cherches « java enum design pattern » sur Google, tu vas être servi.
Parmi les nouveautés de Java 1.5 (en beta jusqu'à cet été) il y a le

support d'un "typesafe" enum...

Bonjour tout seul ;-)

Je débarque dans le monde de java alors merci d'être un peu indulgent si mes
questions vous paraissent un peu légères...

Toutes les questions sont toujours bonnes à poser et soit le bienvenue
en se monde vaste mais passionant ...

Bon, je me lance...
En C++, lorsqu'on créé une méthode d'une classe et qu'on sait que cette
méthode ne modifiera pas l'instance de l'objet, on utilise le mot clé
"const".

ex avec un accesseur :

int MaClasse::GetValue() const
{
return _nValue; // _nValue étant une donnée membre de ma classe.
}

Ma question : existe-t'il un équivalent en java permettant de vérouiller une
méthode de classe pour s'assurer que l'objet ne sera pas modifié ?

Non, il n'existe pas d'equivalent en Java. Le mot clé const est réservé
(si ma mémoire est bonne), mais il ne sert à rien.

Par contre on a le mot clé final qui est bien utile. Il veut dire "ne
peut plus être reaffecter".

Sur une référence (variable ou champ), il signifie qu'une fois la
premère affectation effectuée, il sera impossible d'affecter un autre
objet à cet référence.

Sur une méthode, il empeche de surgarger dans les classes filles la méthode.

Sur une classe, il empeche de dériver la classe.

Avec le temps tu verras que la philosophe de Java est vraiment trés
différente du C++, en Java on est trés "partage" d'objet. Cela semble
"risqué" pour qqn qui vient du C++, mais dans la pratique, en appliquant
certaines règles élémentaires celà se passe plutot trés bien :)

Un peu comme le ramasse mièttes, ceux qui ne sont pas habitués ont
parfois des craintes "existancialistes". Pourtant dans la pratique là
aussi, on se demande comment on a pu coder sans :))

Bon code ...

A+
TM

Merci d'avance...
Chewee

TestMan wrote:

Ma question : existe-t'il un équivalent en java permettant de
vérouiller une méthode de classe pour s'assurer que l'objet ne sera
pas modifié ?

Non, il n'existe pas d'equivalent en Java. Le mot clé const est
réservé (si ma mémoire est bonne), mais il ne sert à rien.

Par contre on a le mot clé final qui est bien utile. Il veut dire "ne
peut plus être reaffecter".

Sur une référence (variable ou champ), il signifie qu'une fois la
premère affectation effectuée, il sera impossible d'affecter un autre
objet à cet référence.

Sur une méthode, il empeche de surgarger dans les classes filles la
méthode.

Sur une classe, il empeche de dériver la classe.

Oui oui, merci, je connaissais le mot clé final.
Il y a plusieurs façon d'utiliser le mot "const" en C++.
Avec le mot clé final en java, tu peux en couvrir un certain nombre, mais
pas pour le cas dont je parlais.
Enfin c'est pas grave, merci quand même

Avec le temps tu verras que la philosophe de Java est vraiment trés
différente du C++, en Java on est trés "partage" d'objet. Cela semble
"risqué" pour qqn qui vient du C++, mais dans la pratique, en
appliquant certaines règles élémentaires celà se passe plutot trés
bien :)

Un peu comme le ramasse mièttes, ceux qui ne sont pas habitués ont
parfois des craintes "existancialistes". Pourtant dans la pratique là
aussi, on se demande comment on a pu coder sans :))

Bon code ...

A+
TM