Discussion :

[AxanOrg]

Bon, je suis bien content que vous confirmiez ce qui commencé à troter dans ma tête, à savoir:
Bon sang mais pourquoi tous les paramètres ne sont ils pas naturellement FINAL !?? (en C++ toutes les références sont lié une seule fois, comme si elles étaient 'final' au sens JAVA).

Mais deuxième problème.
Si final ne permet pas du tout de protéger son objet, mais simplement de protéger la référence, existe t'il un équivalent au powerfull mot clef C++ "const" en JAVA ?
C'est à dire un mot clef spécifiant tout simplement que le paramètre est une ENTREE, et qui garanti donc que celui-ci (l'objet) ne sera pas modifié au sein de la méthode.
Bon sang, il me semble que c'est hachement important comme concept de pouvoir spécifier dans le prototype de ces méthodes que tel paramètre est une entrée, et tel autre non.
Dites moi que c'est prévu en JAVA ?

PS: après queques recherches je n'ai rien trouvé, si ce n'est une ruse de sioux qui consiste à définir 2 classes au lieu d'une, à l'image du couple "String" qui passé en paramètre ne permet pas de modifier l'objet en sortie. et "StringBuffer" qui lui justement le permet.

je m'explique:

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
19
20
 
void ChangeMaChaine(String string, StringBuffer stringbuf)
{
  string = "CaMarchePas";
  stringbuf.setlength(0);
  stringbuf.append("CaMarche");
}
 
// quelque part dans un main...
 
String s = new String("Entree");
StringBuffer sb = new StringBuffer("EntreeSortie");
 
ChangeMaChaine(s, sb);
System.format("String: %s\nStringBuffer: %s", s, sb);
 
/* Affiche :
String: Entree
StringBuffer: CaMarche
*/

[AxanOrg]

Bonjour, j'ai une assez bonne pratique du C++ (je veux dire que j'ai poussé le langage dans pas mal de coins sombres, templates, foncteurs, tout ça..)
et je me met à JAVA parceque ça a l'air merveilleux, sauf que:

Je n'ai pas trouvé comment l'on spécifie dans le prototype de sa méthode les paramètres qui seront des ENTREE, et ceux qui seront des SORTIE (ou E/S..)
Je ne peut pas croire que ça n'existe pas; En C++ il y'a le mot clef "const" pour celà, ça ajoute une vrai garantie que l'objet ne sera pas modifié (vérifié par le compilateur) et je ne peut pas croire que celà n'est pas possible en JAVA..

J'ai fait quelques recherches, le mieu que j'ai trouvé est le mot clef "final" mais ce n'est pas la meme chose.
final permet de spécifier que la REFERENCE est constante, ce que fait naturellement C++ pour toutes ses références (impossible de les modifier) car ça n'aurait de toute manière AUCUN SENS de modifier la référence passée en paramètre, puisque celle-ci est locale à la méthode... On est d'accord ?

Donc, 1ere remarque: il me semble que dans tous les cas, il est bon de mettre TOUS les paramètres, (quelque soit entre ou sortie) en FINAL.

2eme remarque, celà ne résoud pas le problème du const, une référence constante ne fait pas un objet constant.. alors COMMENT FAIRE ?

3eme remarque, ce problème de paramètre constant suppose également qu'on puisse distinguer les méthodes constantes (pour lesqelles 'this' est constant, ex: getters) et celles qui ne le sont pas (ex: setters)). Là non plus je n'ai rien trouvé (en C++ on ajoute le mot clef "const" en bout de ligne du prototype de la méthode).


Hypothèse: JAVA serait un langage merveilleux qui pourrait se passer de ce concept non moins génial parceque par ailleurs il y aurait une façon de penser que je n'ai pas saisie ? Pour l'instant j'en doute.. Mais je veux croire que JAVA est un langage merveilleux (tout comme je voulais croire que la STL c'est portable.. meuh..).


Merci à ceux qui ont la réponse de répondre !!

[adiGuba]

Salut,


Il n'y a pas d'équivalent du const de C++ en Java.

A la place on utilise le principe des classes immuables, c'est à dire de classes dont on ne peut pas modifier la valeur après leurs création.

C'est une logique différente.

a++

[professeur shadoko]

C'est sûr dans un langage "non objet" c'est dejà immoral de concevoir des paramètres en sortie (c'est un truc reservé au "vieux" langages de gestion qui ne s'embarassent pas de la notion d'effet de bord).
En java c'est pas aussi simple : on peut passer en paramètre un objet auquel le code courant va demander des services.... maintenant est ce que la réalisation de ce service va lui-même modifier l'état de l'objet passé en paramètre, est ce que ça va vraiment créer un effet de bord? pas simple!
Si on veut pousser très loin (très loin!) on pourrait: définir une annotation qui détermine si l'invocation d'une méthode modifie l'état de l'objet, puis controler (au compile-time! ouch!) si le code réalisant d'une autre méthode invoque ce code sur un objet passé en paramètre .... C'est de la sur-ingénierie mais, peut-être, pourra t'on exhiber des cas où c'est nécessaire ....
Pour le moment on doit se contenter de limiter intuitivement les effets de bord.

[adiGuba]

Si on veut pousser très loin (très loin!) on pourrait: définir une annotation qui détermine si l'invocation d'une méthode modifie l'état de l'objet, puis controler (au compile-time! ouch!) si le code réalisant d'une autre méthode invoque ce code sur un objet passé en paramètre .... C'est de la sur-ingénierie mais, peut-être, pourra t'on exhiber des cas où c'est nécessaire ....

Cela revient à reproduire le mécanisme du const de C++, qui vérifie seulement à la compilation et selon les déclaration des méthodes (seul les méthodes déclaré en const peuvent être utilisé).

Pour le moment on doit se contenter de limiter intuitivement les effets de bord.

En utilisant des classes immuables on empêche complètement les effets de bord...

a++

[professeur shadoko]

En utilisant des classes immuables on empêche complètement les effets de bord...

Il est vrai qu'on oublie trop souvent de faire des objets immuables. Ceci dit c'est pas toujours possible, ni même souhaitable ... (et lourdingue de faire des "wrappers" qui flinguent les appels de méthodes interdites .. comme dans Collections).
A quand une annotation @const ? (ah oui zut! const est mot-clef!)

[AxanOrg]

Ce que vous apellez "Objets Immuables", c'est par exemple la classe String ? dont le pendant "muable" serait StringBuffer ? c'est ça ?

Si oui, je propose qu'une convention soit addoptée pour spécifier dans le nom de la classe "Immuable" qu'elle est immuable, par exemple: String -> ImmuableString
Quoi c'est long ?

Y'a t'il un mécanisme "générique" pour faire rapido des classes Immuable à partir de notre belle classe muable ? (comme il y'en a pour taper rapido les getters & setters) ?

PS: à ma première question si vous avez répondu "non c'est pas ça", merci de reprendre l'explication

[adiGuba]

Ce que vous apellez "Objets Immuables", c'est par exemple la classe String ? dont le pendant "muable" serait StringBuffer ? c'est ça ?

Oui : une classe immuable est une classe dont on ne peut pas modifier la valeur une fois qu'elle est créée. C'est la raison pour laquelle les méthodes permettant de modifier une String (comme toUpperCase() par exemple) renvoit une nouvelle instance au lieu de modifier l'instance courante...

Si oui, je propose qu'une convention soit addoptée pour spécifier dans le nom de la classe "Immuable" qu'elle est immuable, par exemple: String -> ImmuableString
Quoi c'est long ?

Le problème n'est pas là : il faudrait modifier toutes les applications Java, toutes les API et les frameworks juste pour modifier le nom d'une classe...

Mais plus généralement la grande partie des classes conteneurs sont immuables, en particulier ceux du package java.lang : String, Short, Integer, Long, Float, Double, Boolean, Character, Byte... mais également URI ou URL...

Il y a toutefois des exceptions, en particuliers dans AWT/Swing avec les classes Dimension ou Point, ou encore la classe Date...

Y'a t'il un mécanisme "générique" pour faire rapido des classes Immuable à partir de notre belle classe muable ? (comme il y'en a pour taper rapido les getters & setters) ?

Je ne pense pas qu'il existe d'assistant automatique pour cela. Mais il y a juste quelques points à vérifier :

• La classe doit être final, afin d'être sûr qu'aucune classe fille ne viendra "casser" l'immuabilité...
• Les attributs représentant la valeur de l'objet ne doivent pas être modifié après la création de l'objet. Ils devraient donc être déclaré final (même si ce n'est pas une obligation).
• Aucune des méthodes de la classe ne doit modifier la valeur de l'instance (donc pas de setter). Si on doit avoir des méthodes qui modifie la valeur courante, il faut qu'elles retournent une nouvelle instance...

a++

[edit] Une explication sur les objets immuables : http://www.developpez.net/forums/sho...2&postcount=24

[AxanOrg]

Mais plus généralement la grande partie des classes conteneurs sont immuables, en particulier ceux du package java.lang : String, Short, Integer, Long, Float, Double, Boolean, Character, Byte... mais également URI ou URL...

Ok, et de la même façon qu'a String (Immuable) correspond StringBuffer (Muable) ceux-ci ont ils leur pendant muable ?
Ou existerait il une classe (template par exemple ?) qui permette de "wrapper" rapidement n'importe quelle classe pour la rendre muable ? (en mettant l'instance en attribut public par exemple) ?

Non ? Mais c'est une idée qu'elle est bonne hein ?
[edit] non pas vraiment, puisque notre classe immuable ne doit pas définir de setters .. enfin bon c'est à creuser quoi..

Retour à une de mes questions initiales:
Pour ce qui est de mettre "final" à TOUS, absolument TOUS les paramètres, pour moi qui fait pas mal de C++ ça semble une évidence, ça l'est ou bien c'est une erreur ?
Je ne voi aucun sens (aucune raison valable) pour passer en paramètre une qui serait non finale.
J'ai bon ?

explication:

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
 
String MaMethode(StringBuffer sb)
{
  if (sb.compareTo("oui") == 0)
  {
    sb = new StringBuffer("non");
// Erreur du programmeur.. que le compilo laisse passer, alors que s'il avait mis son paramètre "final" au lieu de manger des fraises ...
// En effet, seule la référence LOCALE à la méthode est modifiée.
    return new String("Mise à oui");
  }
  else
  {
    sb.append("oui"); // Là on modifie bien l'objet, pas la référence.
    sb = new StringBuffer("Mise à non"); // Par contre là ce foutu programmeur utilise volontairement la variable paramètre comme une vulgaire variable temporaire.. C'est MAL.
    return sb.toString();
  }
}

J'espère que cet exemple bidon nous met tous d'accord ?

[adiGuba]

Pour ce qui est de mettre "final" à TOUS, absolument TOUS les paramètres, pour moi qui fait pas mal de C++ ça semble une évidence, ça l'est ou bien c'est une erreur ?

Oui ca l'est. On ne devrait jamais modifier la référence d'un paramètre...

Je ne sais pas s'il y a une raison particulière au fait que les paramètres ne soient pas final par défaut...

a++

[AxanOrg]

J'ai réfléchi, et j'me suis dis..

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
19
20
 
public static void RefDeTableau(String[] stab)
{
	// Je me sert de l'entrée
	if (stab[0].compareTo("Yeah baby") == 0)
	{
		stab[0] = new String("Ca marche baby ?");
	}
	else
	{
		stab[0] = new String("Ca marche tout court ?");
	}
}
 
// Quelque par dans un Main..
 
String[] ma_string_io = {new String("Yeah baby")};
System.out.format("Ma chaine en entrée : %s\n", ma_string_io[0]);
RefDeTableau(ma_string_io);
System.out.format("Ma chaine en sortie : %s\n", ma_string_io[0]);

// Ca nous donne quelque chose comme :
Ma chaine en entrée : Yeah baby
Ma chaine en sortie : Ca marche baby ?

[®om]

Oui ca l'est. On ne devrait jamais modifier la référence d'un paramètre...

Je ne sais pas s'il y a une raison particulière au fait que les paramètres ne soient pas final par défaut...

a++

Peut-être pour une raison pratique, par exemple:

Code :

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

1
2
3
4
5
6
public void method(Options options) {
    /* Si les options sont nulles, on utilise des options par défaut.*/
    if(options == null)
        options = new DefaultOptions();
    ...
}

Ce n'est qu'une hypothèse, et il est vrai aussi qu'il suffirait de créer une nouvelle variable Options, mais bon c'est pratique aussi comme ça

[AxanOrg]

Non, ce n'est pas une bonne façon de faire.
Il faut différencier les paramètres "null" et les "paramètres par défaut".
un paramètre null devrait être considéré dans toute ça nullité.
Pour avoir un paramètre par défaut, on surcharge et pis c'est tout !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void MaMethode(String A, String B/*="Jeannot"*/)
{
  if (A == null) throw new NullPointerException("Et pis c'est tout !");
  if (B == null) throw new NullPointerException("Z'avez ka bien s'tenir !");
 
  ...
}
 
void MaMethode(String A)
{
  MaMethode(A, "Jeannot");
}

Ca ça me parrait l'unique façon correcte de faire pour les paramètres par défaut. Mais je pense que vraiment ça aurait pu être intégré au langage quand même.. (comme en C++ ? hein ? ben oui)

Sinon un ti défi, j'aimerais bien trouve une truc pour réduire ce qui suis à une seule instruction:

Code :

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

1
2
3
4
5
6
7
 
String[] ma_string_io = {new String("Yeah baby")};
System.out.format("Ma chaine en entrée : %s\n", ma_string_io[0]);
 
RefDeTableau(ma_string_io);
 
System.out.format("Ma chaine en sortie : %s\n", ma_string_io[0]);

Avoir un truc du genre :

Code :

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

1
2
3
4
5
6
7
 
String string_io = new String("Yeah baby");
System.out.format("Ma chaine en entrée : %s\n", string_io);
 
RefDeTableau(/*<syntaxe de fou>*/(string_io)/*</syntaxe de fou>*/);
 
System.out.format("Ma chaine en sortie : %s\n", string_io);

Avec vous l'aurez compris une syntaxe de fou qui tienne sur une ligne pour prendre la référence Sring, la mettre dans un tableau de façon qu'elle soit modifiable et de façon transparente..
En fait en écrivant je réfléchi et je pense que c'est impossible.. enfin c'est à peu pret sûr, ma question est bète mais il est 23:48 alors..

[®om]

Code :

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

String[] ma_string_io = {new String("Yeah baby")};

Je ne comprends pas l'intérêt de faire new String("qqch"), qqch à lui tout seul est déjà une String... Et comme String est immutable...

Non, ce n'est pas une bonne façon de faire.
Il faut différencier les paramètres "null" et les "paramètres par défaut".
un paramètre null devrait être considéré dans toute ça nullité.
Pour avoir un paramètre par défaut, on surcharge et pis c'est tout !

Je ne suis pas tout à fait d'accord, car par exemple:

Code :

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

1
2
3
public void method(String a, String b, String c) {
    ...
}

Tu ne peux pas appliquer ce que tu as dit concernant la surcharge pour éviter un paramètre null.

Et ce n'était qu'un exemple, je t'en donne un autre qui peut montrer l'utilité de ne pas avoir un paramètre final...

Code :

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

1
2
3
4
public void method(String name) {
    name = name.toLowerCase();
    ...
}

[AxanOrg]

On tout à fait appliquer la surcharge pour avoir plusieurs paramètres par défaut, à condition de respecter la règle comme en C++ celon laquelle les paramètres "optionnels" doivent être en bout de ligne.

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
 
void MaMethode(String a, String b/*="Bé"*/, String c/*="Cé"*/)
{
  ...
}
 
void MaMethode(String a, String b)
{
  MaMethode(a, b, "Cé");
}
 
void MaMedhode(String a)
{
  MaMethode(a, "Bé", "Cé");
}

On ne peut pas définir c et ne pas définir b, c'est la seule contrainte, mais on s'y fait.

Pour ton exemple du:
name = name.toLowerCase();
Je ne suis pas d'accord !
On ne devrait jamais toucher au paramètre, point final d'abord mais heu !

Code :

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

1
2
3
4
5
6
 
public void method(final String name)
{
  String name_lower = name.toLowerCase();    
    ...
}

Et puis c'est tout ! Ceci ne prete pas à confusion, et c'est pas pour la ptit variable que ça rajoute..

[®om]

Pour ton exemple du:
name = name.toLowerCase();
Je ne suis pas d'accord !
On ne devrait jamais toucher au paramètre, point final d'abord mais heu !

Code :

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

1
2
3
4
5
6
 
public void method(final String name)
{
  String name_lower = name.toLowerCase();    
    ...
}

Et puis c'est tout ! Ceci ne prete pas à confusion, et c'est pas pour la ptit variable que ça rajoute..

C'est exactement ce que j'ai dit plus haut...
Je trouve juste une justification à ce choix...
Je ne discute pas si ce choix est judicieux ou non...