Je n'arrive pas à comprendre quels sont les scénarios où nous avons besoin d'une classe immuable.
Avez-vous déjà été confronté à une telle exigence ? ou pouvez-vous nous donner un exemple réel où nous devrions utiliser ce modèle.
Les autres réponses semblent trop axées sur l'explication des raisons pour lesquelles l'immuabilité est bonne. Elle est très bonne et je l'utilise chaque fois que possible. Cependant, ce n'est pas votre question . Je vais prendre votre question point par point pour m'assurer que vous obtenez les réponses et les exemples dont vous avez besoin.
Je n'arrive pas à comprendre quels sont les scénarios où nous avons besoin d'une classe immuable.
"Besoin" est un terme relatif ici. Les classes immuables sont un modèle de conception qui, comme tout paradigme/modèle/outil, est là pour faciliter la construction de logiciels. De même, beaucoup de code a été écrit avant que le paradigme OO n'apparaisse, mais comptez sur moi pour faire partie des programmeurs qui "besoin" OO. Les classes immuables, comme OO, ne sont pas strictement nécessaire mais je vais agir comme si j'en avais besoin.
Avez-vous déjà été confronté à une telle exigence ?
Si vous ne regardez pas les objets du domaine du problème avec la bonne perspective, vous ne verrez peut-être pas une exigence pour un objet immuable. Il pourrait être facile de penser qu'un domaine problématique n'est pas exiger toute classe immuable si vous ne savez pas quand l'utiliser avantageusement.
J'utilise souvent des classes immuables lorsque je considère qu'un objet donné dans mon domaine de problème est une valeur ou une instance fixe . Cette notion dépend parfois de la perspective ou du point de vue, mais dans l'idéal, il sera facile de passer à la bonne perspective pour identifier les bons objets candidats.
Vous pouvez avoir une meilleure idée de l'emplacement des objets immuables vraiment utile (si ce n'est pas strictement nécessaire) en vous assurant de lire divers livres/articles en ligne afin de développer un bon sens de la manière de penser aux classes immuables. Un bon article pour vous aider à démarrer est Théorie et pratique de Java : Muter ou ne pas muter ?
Je vais essayer de donner quelques exemples ci-dessous de la façon dont on peut voir les objets selon différentes perspectives (mutable vs immuable) pour clarifier ce que j'entends par perspective.
... pouvez-vous s'il vous plaît nous donner un exemple réel où nous devrions utiliser ce modèle.
Puisque vous avez demandé des exemples concrets, je vais vous en donner quelques-uns, mais commençons par des exemples classiques.
Objets de valeur classiques
Les chaînes de caractères et les entiers sont souvent considérés comme des valeurs. Il n'est donc pas surprenant de constater que la classe String et la classe wrapper Integer (ainsi que les autres classes wrapper) sont immuables en Java. Une couleur est généralement considérée comme une valeur, d'où la classe Color immuable.
Contre-exemple
En revanche, une voiture n'est généralement pas considérée comme un objet de valeur. Modéliser une voiture signifie généralement créer une classe dont l'état change (odomètre, vitesse, niveau de carburant, etc.). Cependant, il y a certains domaines où une voiture peut être un objet de valeur. Par exemple, une voiture (ou plus précisément un modèle de voiture) peut être considérée comme un objet de valeur dans une application permettant de rechercher l'huile moteur appropriée pour un véhicule donné.
Cartes à jouer
Vous avez déjà écrit un programme de cartes à jouer ? Moi, je l'ai fait. J'aurais pu représenter une carte à jouer comme un objet mutable avec une couleur et un rang mutables. Une main de poker pourrait être constituée de 5 instances fixes où remplacer la 5e carte de ma main signifierait faire muter la 5e instance de carte à jouer en une nouvelle carte en changeant ses ivars de couleur et de rang.
Cependant, j'ai tendance à considérer une carte à jouer comme un objet immuable qui a une couleur et un rang fixes et immuables une fois créé. Ma main de poker serait composée de 5 instances et remplacer une carte dans ma main impliquerait de se débarrasser d'une de ces instances et d'ajouter une nouvelle instance aléatoire à ma main.
Projection de la carte
Un dernier exemple : j'ai travaillé sur un code de carte où la carte pouvait s'afficher dans différents formats. projections . Dans le code original, la carte utilisait une instance de projection fixe, mais mutable (comme la carte à jouer mutable ci-dessus). Changer la projection de la carte impliquait de modifier les ivars de l'instance de projection de la carte (type de projection, point central, zoom, etc.).
Cependant, j'ai estimé que la conception était plus simple si je pensais à une projection comme une valeur immuable ou une instance fixe. Pour changer la projection de la carte, il fallait que la carte fasse référence à une instance de projection différente plutôt que de modifier l'instance de projection fixe de la carte. Cela simplifiait également la capture de projections nommées telles que MERCATOR_WORLD_VIEW .
Les classes immuables sont en général beaucoup plus plus simple à concevoir, à mettre en œuvre et à utiliser correctement . Un exemple est celui de String : la mise en œuvre de java.lang.String est nettement plus simple que celle de std::string en C++, principalement en raison de son immuabilité.
Un domaine particulier où l'immuabilité fait une différence particulièrement importante est la concurrence : les objets immuables peuvent être partagés entre plusieurs threads en toute sécurité En revanche, les objets mutables doivent être sécurisés par une conception et une mise en œuvre minutieuses, ce qui est loin d'être une tâche triviale.
Mise à jour : Java efficace 2ème édition aborde cette question en détail - voir Point 15 : minimiser la mutabilité .
Voir aussi ces articles connexes :
Effective Java de Joshua Bloch expose plusieurs raisons d'écrire des classes immuables :
En général, il est bon de rendre un objet immuable, sauf si cela entraîne de graves problèmes de performances. Dans de telles circonstances, les objets constructeurs mutables peuvent être utilisés pour construire des objets immuables, par exemple StringBuilder.
Les hashmaps en sont un exemple classique. Il est impératif que la clé d'une carte soit immuable. Si la clé n'est pas immuable, et que vous modifiez une valeur de la clé de telle sorte que hashCode() donne une nouvelle valeur, la carte est maintenant cassée (une clé se trouve maintenant au mauvais endroit dans la table de hachage).
Je dirais plutôt qu'il est impératif que la clé ne soit pas modifiée ; il n'y a cependant pas d'exigence officielle pour qu'elle soit immuable.
Je pense qu'il veut dire que la seule exigence réelle est que les clés ne doivent pas être modifiées... et non qu'elles ne peuvent pas être modifiées du tout (via l'immuabilité). Bien sûr, un moyen facile d'empêcher les clés d'être modifiées est de les rendre immuables dès le départ ! :-)
Nous ne besoin de Les classes immuables, en soi, mais elles peuvent certainement faciliter certaines tâches de programmation, notamment lorsque plusieurs threads sont impliqués. Vous n'avez pas besoin d'effectuer de verrouillage pour accéder à un objet immuable, et tous les faits que vous avez déjà établis à propos d'un tel objet resteront vrais à l'avenir.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
14 votes
Je suis surpris que personne n'ait dit qu'il s'agissait d'un doublon. On dirait que vous essayez juste d'accumuler des points faciles... :) (1) stackoverflow.com/questions/1284727/mutable-or-immutable-class (2) stackoverflow.com/questions/3162665/immutable-class (3) stackoverflow.com/questions/752280/