Pourquoi String est-elle final ?

Bonsoir,

Je cherche à gérer ma collection de Babar.
J'ai donc le même livre traduit dans différentes langues :
- Babar voyage
- Travel of Babar
- Babar, konishiwa Fujiyama !

J'ai donc pensé que l'objet Book possédait la variable List<Title> titleList dont l'implémentation de Title est :
Code:

1 2 3 4 public class Title extends String { private Locale locale; ... }
qui me permet d'avoir les titres selon la langue.

Mais depuis java 5 me semble-t-il, String devenue final. Je ne peux donc pas écrire ce code.

D'où ma question. Quelle est la raison pour que String soit final ? Je ne vais réimplémenter String pour lui ajouter une fonctionnalité dont j'ai besoin.

Pour la même raison que Integer /Float / ... sont final. Ce sont des composants de base.
Code:

1 2 3 4 5 public class Title { private Locale locale; private String value ... }
En quoi une composition dérange?

C'est justement parce que c'est un composant de base qu'il est intéressant de pouvoir l'étendre !

Alors, je te l'accorde, une composition peut être une solution, solution qui en soit n'est pas très compliquée car il me suffirait d'écrire :
Code:

1 2 3 4 5 6 7 8 9 public class Title { private Locale locale; private String value; public int length() { return value.length(); } ... }
Mais du coup, je deviens "responsable" des constructeurs, des méthodes et des javadocs afférents à la classe String. C'est donc contraire au principe de l'héritage objet qui consiste à ajouter des fonctionnalités à une classe avec un minimum de risque (notamment ceux dûs aux copier-coller). Ensuite, lors d'une mise à jour de la jdk, je dois en plus maintenir le code de cette classe afin d'appeler les potentielles nouvelles méthodes ou supprimer les appels à des méthodes dépréciées (enfin ?) supprimées. Bref, pisser du code inutilement et maintenir du code inutilement.

Maintenant, tu t'y connais probablement plus que moi, et si je n'ai pas d'autre choix, j'opterais pour cette solution.

Qu'est ce que tu entends par devenir responsable des méthodes et constructeurs? Au delà de ça string a un certain nombre de comportements qui deviendraient instables avec une sous classe. par exemple le fait que cette classe soit immuable, son utilisation dans les switch case...
A noter que tu peux aussi étendre charsequence si tu préfère.

Autre détail, les strings comme l'autoboxing étant utilisés fortement par les codes, les rendre finaux permet à la jvm un certain nombre d'optimisations et raccourcis de calcul qui sont importants pour avoir des performances potables :-)

Salut,

String est surtout final afin de s'assurer de l'immutabilité de la classe.
Et c'est très important car cela permet de partager une instance sans avoir peur qu'elle ne soit modifiée par ailleurs.
En effet rien ne garantie que les classes filles conservent cette notion, et du coup on ne pourrait plus considérer String comme immuable.

Si tu supprimes cela tu casses potentiellement tous les programmes Java, et il faudrait gérer des copies de tous les cotés...

a++

Je trouve dommage que cette notion d'immutabilité implique que la classe soit final et pas uniquement les variables de classe privées et ses méthodes.

Mais visiblement, le débat a déjà eu lieu :
http://gfx.developpez.com/tutoriel/java/immuables/
"Les développeurs Java connaissent tous très bien la notion de classe immuable. Beaucoup ont d'ailleurs pesté contre sa principale représentante, java.lang.String."

Merci messieurs pour vos explications.

Citation:

Envoyé par sql_ignorant

Je trouve dommage que cette notion d'immutabilité implique que la classe soit final et pas uniquement les variables de classe privées et ses méthodes.

Si une classe peut être hérité, elle a potentiellement une infinité de classe fille... et rien ne peut garantir qu'elle seront toute immuable.
Et donc cela empêcherait de considérer la classe parente comme immuable...

Pour la composition, tu peux tout simplement te contenter de ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public final class Title { private final Locale locale; private final String value; public Title(Locale locale, String value) { this.locale = locale; this.value = value; } public Locale getLocale() { return this.locale; } public String getValue() { return value; } }
Quoi que dans ton cas ta List<Title> pourrait peut-être être remplacé par une Map<Locale,String>...

a++

Mais visiblement, le débat a déjà eu lieu :
http://gfx.developpez.com/tutoriel/java/immuables/
"Les développeurs Java connaissent tous très bien la notion de classe immuable. Beaucoup ont d'ailleurs pesté contre sa principale représentante, java.lang.String."

Merci messieurs pour vos explications.[/QUOTE]

Citation:
Envoyé par adiGuba
Pour la composition, tu peux tout simplement te contenter de ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public final class Title { private final Locale locale; private final String value; public Title(Locale locale, String value) { this.locale = locale; this.value = value; } public Locale getLocale() { return this.locale; } public String getValue() { return value; } }
Oui, c'est ce que j'ai fait.

Citation:

Envoyé par adiGuba

Quoi que dans ton cas ta List<Title> pourrait peut-être être remplacé par une Map<Locale,String>...

Dans cet exemple précis, oui, mais non car je veux contrôler plus finement le contenu de ma string, mais c'est un autre débat.

Revenons sur l'immutabilité. Je sais que le langage ne le permet pas, mais Sun/Oracle ont la main sur ce que le langage permet ou non. Alors pourquoi n'on-ils pas donner la possibilité de mettre les constructeurs final ?
Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class Title { private final Locale locale; private final String value; public final Title(Locale locale, String value) { this.locale = locale; this.value = value; } public Locale getLocale() { return this.locale; } public String getValue() { return value; } }
Ainsi, la classe devient immuable tout en restant héritable :
Code:

1 2 3 4 5 6 7 8 public class ColoredTitle extends Title { private Color color; public ColoredTitle(Locale locale, String value, Color color) { super(locale, value); this.color = color; } }

Parce que ça empêcherait d'écrire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class ColoredTitle extends Title {
	private Color color;
 
	public ColoredTitle(Locale locale, String value, Color color) {
		super(locale, value);
		this.color = color;
	}
 
	public ColoredTitle(Locale locale, String value) {
		this(locale, value, null);
	}
 
	public void setColor(Color color) {
		this.color = color;
	}
}

Ok, j'ai rien dit.

Le constructeur n'est pas le problème.

Le problème c'est qu'en héritant tu peux rajouter des champs dans une classe fille, et donc tu peux modifier son état.

Dans ton exemple même si tous ses champs sont finaux, on ne peut pas considérer Title comme immutable car elle peut avoir des classes filles...
Ta classe ColoredTitle pourrait très bien avoir une méthode setColor() qui modifierait la couleur.
Du coup on pourrait stocker une instance de Title qui serait modifié par la suite... ce qui rompt le concept d'immuabilité.

Ce n'est pas vraiment une restriction au niveau du langage, mais plus globalement au niveau du concept d'immutabilité.
D'ailleurs il n'y a pas vraiment de notion d'immuabilité au niveau du langage...

a++

Je trouve cette discussion très intéressante car il y a un truc qui semble m'échapper.
Si je comprends bien le concept d’immutabilité, le but (final :p) est d'empêcher une instance de changer de valeur en cours d'execution et d'obliger la création d'une nouvelle instance du-dit objet. Ainsi, la comparaison de pointeur est fausse (string1 != string2).

Citation:

Envoyé par adiGuba

on pourrait stocker une instance de Title qui serait modifié par la suite... ce qui rompt le concept d'immuabilité.

Mais dans le cas d'une composition, rien ne m'empêche de modifier l'instance du composé.
Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class Title { private final Locale locale; private final String value; public final Title(Locale locale, String value) { this.locale = locale; this.value = value; } public Locale getLocale() { return this.locale; } public String getValue() { return value; } }
Même si la classe String est immuable, j'ai le droit d'écrire :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public class Title { private final Locale locale; private String value; public final Title(Locale locale, String value) { this.locale = locale; this.value = value; } public Locale getLocale() { return this.locale; } public String getValue() { return value; } public void setValue(String value) { this.value = value; } }
Du coup, je stocke une instance de String qui peut être modifiée par la suite. Donc rendre String final n'a pas résolu la notion d’immutabilité.

La String est bien immuable. Dans ton exemple, c'est Title qui n'est pas immuable

Ok.

Merci messieurs.