[optimisation de code] mot clé this et objet = null

Bonjour messieurs je me pose des questions :

Certaines personne sur le projet sur lequel je suis, on un code qui ne me parait vraiment bizard je ne comprends pas pourquoi ils font ça. Est-ce que quelqu'un peut me dire s’il s’agit d'une optimisation du code ou juste un code spécifique a certains développeurs ? :
-Première interrogation est sur le mot clé this

Code:

---

1 2 3 4 5 6 7 8 9

public class Kom {   /** L'ancienne valeur */ private String oldValue;   public void doplop() { this.oldValue = "plop"; }

---

J'aimerais juste savoir si c'est une convention ou alors si c'est une optimisation car perso je trouve ca moche j'utilise directement la variable sans le this.

-Deuxième interrogation :

Code:

---

1 2 3 4 5 6 7 8

public class Kom {   public void doplop() { obj = null // obj et obj2 sont de même type obj = obj2 }

---

C'est une optimisation de mettre l'objet a null avant de faire le passage par référence ?

Merci d’avance.
Cordialement.

Je vais peut-être montre mon ignorance mais pour moi les deux exemples sont uniquement des questions de style. Je ne vois aucune optimisation à run-time.

Dans l'exemple 1, le 'this' permet parfois de distinguer un champ d'un paramètre. L'exemple typique est le constructeur ou le setter:

Code:

---

this.value = value;

---

Citation:

---

Envoyé par Malatok

-Première interrogation est sur le mot clé this

Code:

---

1 2 3 4 5 6 7 8 9

public class Kom {   /** L'ancienne valeur */ private String oldValue;   public void doplop() { this.oldValue = "plop"; }

---

J'aimerais juste savoir si c'est une convention ou alors si c'est une optimisation car perso je trouve ca moche j'utilise directement la variable sans le this.

---

C'est une convention. Dans cet exemple, elle est discutable.

Regardons, par contre, cet exemple :

Code:

---

1 2 3 4 5 6 7

class A { private String value;   public void setValue(String value) { this.value = value; } }

---

Ici, la variable membre, et le paramètre de la méthode setValue(), portent le même nom. Java dit que dans ce cas-là, le nom du paramètre masque le nom de la variable membre.

Pour accéder quand même à la variable membre, on utilise this.
Ceci est une convention très répandue dans les setters.

Citation:

---

Envoyé par Malatok

-Deuxième interrogation :

Code:

---

1 2 3 4 5 6 7 8

public class Kom {   public void doplop() { obj = null // obj et obj2 sont de même type obj = obj2 }

---

C'est une optimisation de mettre l'objet a null avant de faire le passage par référence ?

---

Je ne vois pas de "passage par référence."

Assigner une valeur à une variable, puis lui assigner une autre valeur sans s'en être servi entre les deux, est inutile. Ça n'a pas d'effet et est ignoré par le compilateur.
Dans cet exemple, donc, l'assignation à null n'a servi à rien.

Mais dans des exemples plus complets, initialiser une variable à null avant de pouvoir en faire quelque chose, peut s'avérer nécessaire, ou au moins un raccourci sympathique.

Citation:

---

Je ne vois pas de "passage par référence."

---

Pas très parlant mon exemple mais la je parlais d'un objet que l'on met a null, et ensuite sur lequel on vient faire un passage par référence de obj2 vers obj1(copie du contenu de l’objet2 vers l’objet1 ). Est-ce que par hasard quand tu lui passe la valeur null le compilateur ne va pas directement construire l’objet avec le constructeur par défaut et donc ca va allez plus vite de faire la copie de l’obj2 vers l’obj1 que de faire tout en même temps ?

Salut,

Citation:

---

Envoyé par Malatok

Pas très parlant mon exemple mais la je parlais d'un objet que l'on met a null, et ensuite sur lequel on vient faire un passage par référence de obj2 vers obj1(copie du contenu de l’objet2 vers l’objet1 ). Mais c’est vrai que la comme ca pas évident de comprendre.

---

Ce n'est pas un "passage par référence" mais une "affectation". La seule "copie" qui est faite est celle de la référence. Il n'y a pas de copie du contenu des objets !!!



Sinon le fait de mettre la valeur à null ne sert à rien ou presque.
La seule utilité que je verrais ce serait pour éviter des OutOfMemoryException si l'objet référencé occupe une taille importante en mémoire, et qu'on voudrait le remplacer par un objet aussi grand... Mais c'est vraiment ultra-ultra spécifique...



a++

PS : Au passage l'optimisation ne se fait pas sur des "astuces" ou des "mot-clef", mais sur un choix algorithmiques et l’utilisation d'objets et de données approprié au besoin...

Citation:

---

Ce n'est pas un "passage par référence" mais une "affectation". La seule "copie" qui est faite est celle de la référence. Il n'y a pas de copie du contenu des objets !!!

---

Très juste les obj1 et obj2 pointe sur le même objet en mémoire.(Désoler je me suis un peu emballer ...).

En ce qui concerne la premiere question, parfois this est necessaire (comme deja dit) et parfois non. Dans tous les cas, c'est à chacun de decider s'il le met systématiquement ou non. En ce qui me concerne, je le met toujours parce que je trouve ca plus lisible. Mais ce n'est qu'une convention (qui ne change rien au niveau de l'execution ou bien sur le fichier .class obtenu)...

Pour la 2e question, j'imagine que ce que tu veux savoir, c'est s'il y a un interet à initialiser d'abord à null puis à affecter un objet. S'il y en a 1, je ne le vois pas (d'ailleurs, il y a des chances qu'a la compilation, l'initialisation saute). Mais c'est parfois une habitude qu'on pris certains developpeurs qui viennent du c/c++ d'initialiser systematiquement les pointeurs pour eviter d'utiliser des pointeurs non initialisés. Ca peut aussi est un code qui a été retouché et qui a gardé ca... Mais concretement, ce n'est pas une optimisation...

L'affectation à null est parfois nécessaire. Par exemple :

Code:

---

1 2 3 4 5 6 7 8

public void foo(boolean test) { String str1; String str2 = "..."; if (test) { str1 = str2; } str1.length(); }

---

Ce code ne compile pas car str1 n'a pas été initialisé et on ne peut donc pas invoquer la méthode length().

Citation:

---

Envoyé par +Guilhem

L'affectation à null est parfois nécessaire. Par exemple :

Code:

---

1 2 3 4 5 6 7 8

public void foo(boolean test) { String str1; String str2 = "..."; if (test) { str1 = str2; } str1.length(); }

---

Ce code ne compile pas car str1 n'a pas été initialisé et on ne peut donc pas invoquer la méthode length().

---

Pas génial cet exemple. Si on initialise str1 à null, str1.length() générera un NullPointerException et puis c'est tout, c'est encore moins bien que ne pas compiler du tout.
Je ne trouve pas de vrai exemple parlant sans m'enfoncer dans une certaine complexité. Il y a la fermeture des flux, à la rigueur, avant l'apparition de try-with-resource.

Citation:

---

Envoyé par thelvin

Il y a la fermeture des flux, à la rigueur, avant l'apparition de try-with-resource.

---

Même pas... Je ne vois pas en quoi il faudrait faire une affectation à null. Le try/finally suffit amplement !


a++

Citation:

---

Envoyé par adiGuba

Même pas... Je ne vois pas en quoi il faudrait faire une affectation à null. Le try/finally suffit amplement !

---

Quand il y a une seule ressource à fermer, ok, mais quand il y en a plusieurs ça devient vraiment lourd sans une petite initialisation à null.

Citation:

---

Envoyé par thelvin

Pas génial cet exemple. Si on initialise str1 à null, str1.length() générera un NullPointerException et puis c'est tout, c'est encore moins bien que ne pas compiler du tout.
Je ne trouve pas de vrai exemple parlant sans m'enfoncer dans une certaine complexité. Il y a la fermeture des flux, à la rigueur, avant l'apparition de try-with-resource.

---

C'était juste pour illustrer que parfois nous sommes obligés d'initialiser une variable à null.

Remplace str1.length(); par bar(str1); (bar étant une méthode quelconque), ça revient au même, ça compilera pas et en initialisant str1 à null aucune exception n'est levée.

Quand il y en a plusieurs, il est préférable d'empiler les try/finally. C'est plus sûr et plus court ;)

a++

Citation:

---

Envoyé par adiGuba

Même pas... Je ne vois pas en quoi il faudrait faire une affectation à null. Le try/finally suffit amplement !

---

Bah pour prendre un exemple, si on ouvre un fichier et qu'on met son contenu dans un autre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

FileInputStream fis = null; FileOutputStream fos = null; try { fis = new FileInputStream("c:\\in.txt"); fos = new FileOutputStream("c:\\out.txt");   // On transfert de l'un vers l'autre avec un eventuel traitement } catch (Exception ex) { ex.printStackTrace(); } finally { if (fis != null) { try { fis.close(); } catch (Exception ex) { ex.printStackTrace(); } } if (fos != null) { try { fos.close(); } catch (Exception ex) { ex.printStackTrace(); } } }

---

Tu ferais comment sans initialiser à null?

Pour moi, moins il y a de mots dans les sources et plus c'est lisible. Donc un "this." en trop ou une initialisation en trop, bin, c'est en trop :)

Pour le "this", je préfère ne le mettre que quand il faut (rarement, donc...), ainsi ça met en évidence l'endroit où il pourrait y avoir confusion. Pour le null, il me semble que dans les specs, un objet non initialisé est toujours null, non ?

L'initialisation à null n'est vraie que pour les variables d'instance.
Les variables locales d'une méthode doivent être initialisées avant d'être utilisées.

Citation:

---

Envoyé par BenWillard

Pour le null, il me semble que dans les specs, un objet non initialisé est toujours null, non ?

---

C'est seulement vrai pour les attributs.

Une variable locale non-initialisé provoquera une erreur de compilation si on tente d'y accéder sans qu'elle ne soit spécifiquement initialisé...

Citation:

---

Envoyé par hwoarang

Bah pour prendre un exemple, si on ouvre un fichier et qu'on met son contenu dans un autre :

---

Cette syntaxe est assez lourde à cause des multiples try/catch.
De plus il n'est pas aisé de laisser remonter l'exception (parce qu'un printStackTrace() à ce niveau n'est peut-être pas le meilleur choix).

Citation:

---

Envoyé par hwoarang

Tu ferais comment sans initialiser à null?

---

En utilisant un bloc try/finally par ressource.
Et si on a besoin de traiter les exceptions on rajoute un try/catch...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

try { FileInputStream fis = new FileInputStream("c:\\in.txt"); try { FileInputStream fos = new FileOutputStream("c:\\out.txt"); try { // On transfert de l'un vers l'autre avec un eventuel traitement } finally { fos.close(); } } finally { fis.close(); } } catch (IOException e) { e.printStrackTrace(); }

---

C'est grosso-modo le pattern adopté par le try-with-resources de Java 7...


a++

Citation:

---

Une variable locale non-initialisé provoquera une erreur de compilation si on tente d'y accéder sans qu'elle ne soit spécifiquement initialisé...

---

Dans ma config, ça me donne un warning ...

Citation:

---

Envoyé par BenWillard

Dans ma config, ça me donne un warning ...

---

C'est quoi ta config ? javac provoquera une erreur quoi qu'il arrive.

a++

Ma config c'est Eclipse, avec une config perso des erreurs de compil...

Mais en fait ça me donne un warning pour "potential null pointer access"...

Si j'initialise un truc dans la partie "try" du "try-catch", et pas dans le catch, et l'utilise plus tard, je n'ai aucune erreur à la compil, il me semble.

T'as pas un exemple ? que je puisse tester précisément.

Citation:

---

Envoyé par BenWillard

Dans ma config, ça me donne un warning ...

---

Le warning doit t'être indiqué si ta variable n'est jamais utilisée.

Citation:

---

Envoyé par BenWillard

Ma config c'est Eclipse, avec une config perso des erreurs de compil...

---

Je savais qu'eclipse gérait des warnings supplémentaires... mais pas qu'il occultait des erreurs !!!

Citation:

---

Envoyé par BenWillard

T'as pas un exemple ? que je puisse tester précisément.

---

Tout simplement :

Code:

---

1 2 3 4 5 6

public void method() { String str; if(str!=null) {   } }

---

A la compilation :

Code:

---

1 2	Main.java:14: variable str might not have been initialized if(str!=null) {

---

a++

ah non, ok, ça me donne en effet "The local variable str may not have been initialized" ... Du coup ça confirme que ça ne sert à rien d'initialiser systématiquement : dans le cas où il le faut vraiment et qu'on oublie, ça ne compile même pas...