Discussion :

[fabszn]

hello,

Je me posais la question suivante :

quel est l'interet de declarer des parametres final?

Est ce que cela indique que les parametres sont passé par valeur et non par reference?

Merci d'avance,

[Oui-Oui MB]

Cela permet de ne pas pouvoir redéfinir la variable par après, dans le cas d'une variable.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
final int VALUE_FINAL = 1;
 
private void maFct()
{
  VALUE_FINAL = 2; // Pas permis...
}

Ca permet aussi, en l'utilisant avec "class" (-> final class Machin) de pas pouvoir faire un héritage sur cette classe.

[Deadpool]

Tu veux dire l'intérêt de faire ça ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public void maMéthode (final MonObjet monParamètre){
 
}

[fabszn]

Cela permet de ne pas pouvoir redéfinir la variable par après, dans le cas d'une variable.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
final int VALUE_FINAL = 1;
 
private void maFct()
{
  VALUE_FINAL = 2; // Pas permis...
}

Ca permet aussi, en l'utilisant avec "class" (-> final class Machin) de pas pouvoir faire un héritage sur cette classe.

Oui ca pas de probleme, je connaissais!
Par contre, c'est l'utilisation dans le cas décrit par Descent.

Ou je ne suis pas sur de comprendre...

[fabszn]

Tu veux dire l'intérêt de faire ça ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public void maMéthode (final MonObjet monParamètre){
 
}

Oui! Est ce pour un passage par valeur et non par reference?

[Baptiste Wicht]

Tu veux dire l'intérêt de faire ça ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public void maMéthode (final MonObjet monParamètre){
 
}

Oui! Est ce pour un passage par valeur et non par reference?

Je ne pense pas, c'est juste l'intéret de passer une variable qui sera ensuite constante dans la méthode, mais ca ne change rien au passage par valeur ou référence

[Deadpool]

Non rien à voir. De toute façon en Java tout est passé par valeur. Si si je te jure c'est vrai. Y'a moult discussions mouvementées sur le sujet.

Sinon, l'intérêt de passer des paramètres en final, je crois que c'est simplement pour des effets d'optimisation. Tu sais que la valeur de ton paramètre ne change pas dans la méthode, tu le déclare en final de cette façon le compilateur java va pouvoir faire des optimisations dessus.

C'est ce que j'ai compris en parcourant cette page (paragraphe D.1.2 New Uses for final).

Note : cette page date un peu quand même...

[fabszn]

Hello,

Je ne vois pas l'interet..Ca donne un statut un peut ambigu à la variable!

Qu'en pensez vous?

[REEDITION]

Oui moult et moult discussion à propos de passage par reference et non par valeur...

Je viens de lire l'article.. je reviens sur ce que j'ai dit... Effectivement cela presente un interet pour l'optimisation... et cette notion de protection de parametre!

Merci pour vos réponses! et pour le lien...

[Oui-Oui MB]

Dans ce cas, il ne faut plus parler de variable mais de paramètre dans le sens où celui-ci n'est jamais que lu.

C'est un peu comme le const de C++. Ca permet de garantir que le paramètre ne changera pas au cours de la fonction.

[Satch]

Justement pas.

Et c'est une bonne habitude à prendre de déclarer tout les paramètres de méthode finaux pour 2 raisons :
- optimisation
- vu que ce sont des paramètres de méthode, il n'y a aucune raison logique pour que leur valeur change.

[Satch]

en clair, on protege l'objet passé en parametre d'une modification dans la méthode (ca ne compile pas).

Attention !!!
Une référence à un objet déclarée finale ne permet pas de changer la référence. PAr contre l'objet, lui, peut être modifié.

EDIT : Tiens... le message auquel je répond a disparu :p . Le fautif aurait-il remarqué sa faute ? ;)

[fabszn]

en clair, on protege l'objet passé en parametre d'une modification dans la méthode (ca ne compile pas).

Attention !!!
Une référence à un objet déclarée finale ne permet pas de changer la référence. PAr contre l'objet, lui, peut être modifié.

Ok... mais est ce que modifier l'objet presente un interet si la reference ne l'etre pas? :

[Satch]

Ok... mais est ce que modifier l'objet presente un interet si la reference ne l'etre pas? :roll: :?:

bien sur, ça permet d'être sur d'avoir toujours le même objet dans ta méthode.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class A {
   int i=0;
}
 
class Test{
 
   blabla blalba main (...){
 
     A a = new A();
     incremente(a);
 
  }
 
  static void incremente(final A a){
      a.i++; //permis
      a = new A(); // pas permis
  }
}

[Deadpool]

Je pense que ça a quand même une utilité, notamment quand tu utilise des classes internes anonymes.

Exemple tu ecrit une méthode qui ajoute un écouteur à un bouton pour que celui ci quand tu clique dessus affiche dans une boîte de dialogue la valeur de l'int que tu passe en paramètre de ta méthode (c'est bidon c'est juste pour l'exemple).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
public void ajouterEcouteur(int valeurAAffichier){
       monBouton.addActionListener(new ActionListener(){
                   public void actionPerformed(ActionEvent e) {
                               JOptionPane.showMessageDialog(null, valeurAAfficher);
                   }
       });
}

Dans le cas présent le code ne va pas compiler car lorsque une classe interne utilise une variable définie en dehors de celle-ci, il faut que cette variable soit final.

Conclusion : il faut mettre le int valeurAAfficher en final comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
public void ajouterEcouteur( final int valeurAAffichier){
       monBouton.addActionListener(new ActionListener(){
                   public void actionPerformed(ActionEvent e) {
                               JOptionPane.showMessageDialog(null, valeurAAfficher);
                   }
       });
}

Et là, le compilateur ne va pas gueuler.

[Satch]

Ha oui tiens, j'avais oublié ce détail. C'est toujours bon à rappeler :)

[Deadpool]

Je m'en souvenais car j'ai eu un cas comme ça récemment.

[fabszn]

Je pense que ça a quand même une utilité, notamment quand tu utilise des classes internes anonymes.

Exemple tu ecrit une méthode qui ajoute un écouteur à un bouton pour que celui ci quand tu clique dessus affiche dans une boîte de dialogue la valeur de l'int que tu passe en paramètre de ta méthode (c'est bidon c'est juste pour l'exemple).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
public void ajouterEcouteur(int valeurAAffichier){
       monBouton.addActionListener(new ActionListener(){
                   public void actionPerformed(ActionEvent e) {
                               JOptionPane.showMessageDialog(null, valeurAAfficher);
                   }
       });
}

Dans le cas présent le code ne va pas compiler car lorsque une classe interne utilise une variable définie en dehors de celle-ci, il faut que cette variable soit final.

Conclusion : il faut mettre le int valeurAAfficher en final comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
public void ajouterEcouteur( final int valeurAAffichier){
       monBouton.addActionListener(new ActionListener(){
                   public void actionPerformed(ActionEvent e) {
                               JOptionPane.showMessageDialog(null, valeurAAfficher);
                   }
       });
}

Et là, le compilateur ne va pas gueuler.

Merci pour cet exemple.. effectivement, l'utilisation du parametre declaré final est clairement mis en evidence dans ce cas la!!