Les inconvénients des objets immuables en Java ?

Question

Les avantages des objets immuables en Java semblent évidents :

• état constant
• sécurité automatique du fil
• simplicité

Vous pouvez favoriser l'immuabilité en utilisant des champs privés finaux et l'injection de constructeurs.

Mais quels sont les inconvénients à favoriser les objets immuables en Java ?

c'est-à-dire

• incompatibilité avec les outils ORM ou de présentation web ?
• Une conception inflexible ?
• Complexités de mise en œuvre ?

Est-il possible de concevoir un système à grande échelle (graphe d'objets profond) qui utilise principalement des objets immuables ?

Answer 1

Mais, quels sont les inconvénients de favoriser les objets immuables en Java ? incompatibilité avec les ORM ou le web outils de présentation ?

Les cadres basés sur Reflection sont compliqués par les objets immuables puisqu'ils nécessite injection du constructeur :

• il n'y a pas d'arguments par défaut en Java, ce qui nous oblige à TOUJOURS fournir toutes les dépendances nécessaires
• le remplacement du constructeur peut être désordonné
• les noms des arguments des constructeurs ne sont généralement pas disponibles par réflexion, ce qui nous oblige à dépendre de l'ordre des arguments pour la résolution des dépendances

Complexités de mise en œuvre ?

La création d'objets immuables reste une tâche ennuyeuse ; le compilateur devrait s'occuper des détails d'implémentation, comme dans le cas de groovy

Est-il possible de concevoir un système à grande échelle (graphe d'objets profond) qui utilise principalement des objets immuables ?

définitivement oui ; les objets immuables constituent d'excellents blocs de construction pour d'autres objets (ils favorisent la composition) car il est beaucoup plus facile de maintenir l'invariant d'un objet complexe lorsque vous pouvez vous appuyer sur ses composants immuables. Le seul véritable inconvénient, à mon avis, est la création de nombreux objets temporaires (par ex. La concaténation des chaînes de caractères était un problème dans le passé ).

Answer 2

Avec l'immuabilité, chaque fois que vous devez modifier des données, vous devez créer un nouvel objet. Cela peut être coûteux.

Imaginez que vous ayez besoin de modifier un bit dans un objet qui consomme plusieurs mégaoctets de mémoire : vous devriez instancier un tout nouvel objet, allouer de la mémoire, etc. Si vous devez faire cela plusieurs fois, la mutabilité devient très intéressante.

Answer 3

Si vous optez pour la mutabilité, vous constaterez qu'à chaque fois que vous devez appeler une méthode dont vous ne voulez pas que l'objet change, ou que vous devez renvoyer un objet qui fait partie de l'état interne, vous devez faire une copie défensive.

Si vous examinez vraiment les programmes qui utilisent des objets muables, vous constaterez qu'ils sont sujets à des "attaques" par modification :

• les objets passés aux constructeurs
• objets passés aux méthodes
• les objets renvoyés par les méthodes.

Le problème ne se pose pas très souvent car la plupart des programmes ne modifient pas les données (elles sont en réalité immuables puisqu'elles ne changent jamais).

Je fais personnellement tout ce que je peux finaliser. J'ai probablement 90%-95% de toutes les variables (paramètres, locales, d'instance, statiques, exceptions, etc...) marquées comme finales. Dans certains cas, elles doivent être mutables, mais dans la grande majorité des cas, elles ne le sont pas.

Je pense que cela peut dépendre de votre objectif. Si vous écrivez des bibliothèques destinées à être utilisées par des tiers, vous y pensez beaucoup plus que si vous écrivez une application que seul vous (ou votre équipe) maintiendrez.

Je trouve que l'on peut écrire des applications à grande échelle en utilisant des objets immuables pour la majorité du système sans trop de difficultés.

Answer 4

Fondamentalement, dans le monde réel, l'état associé à de nombreuses identités particulières changera. Si je demande quelle est "la position actuelle de la Buick de Joe", il se peut qu'aujourd'hui ce soit un emplacement à Seattle, et demain un emplacement à Los Alamos. Il serait possible de définir et de créer une GeographicLocation objet dont la valeur représentera toujours l'endroit où se trouvait la Buick de Joe à un moment donné dans le temps et ne changera jamais - si aujourd'hui il représente un endroit à Seattle, il en sera toujours ainsi. Un tel objet, cependant, n'aurait pas d'identité permanente en tant que "l'emplacement actuel de la Buick de Joe".

Il peut également être possible de définir les choses de manière à ce qu'il y ait une VehicleLocation un objet qui est relié à la Buick de Joe de telle sorte que l'objet représente toujours "l'emplacement actuel de la Buick de Joe". Un tel objet pourrait conserver son identité en tant que "l'emplacement actuel de la Buick de Joe", même lorsque la voiture se déplace, mais il ne représenterait pas un emplacement géographique constant. Définir l'"identité" peut être délicat si l'on considère le scénario où Joe vend sa Buick à Bob et achète une Ford - l'objet doit-il suivre "l'emplacement actuel de la Ford de Joe" ou "l'emplacement actuel de la Buick de Bob" - mais dans de nombreux cas, ces problèmes peuvent être évités en utilisant un modèle de données qui garantit que certains aspects de l'identité de l'objet ne changeront jamais.

Il n'est pas possible que tout ce qui concerne un objet soit immuable. Si un objet est immuable, il ne peut pas avoir une identité immuable qui englobe quelque chose au-delà de son état actuel. En revanche, si un objet est mutable, il peut avoir une identité immuable dont la signification transcende son état actuel. Dans de nombreuses situations, il est plus utile d'avoir une identité immuable que d'avoir un état immuable, et dans de telles situations, les objets mutables sont presque essentiels. Bien qu'il soit possible dans certains cas de "simuler" des objets mutables en ayant un objet immuable qui chercherait dans la version la plus récente d'un objet immuable pour trouver des informations qui peuvent "changer" entre une version et la suivante, de telles approches sont souvent extrêmement inefficaces. Même si l'on pouvait recevoir par magie, une fois par minute, un livre relié indiquant l'emplacement de tous les véhicules du monde entier, rechercher la "Buick de Joe" dans ce livre prendrait beaucoup plus de temps que de demander simplement à un objet "emplacement actuel de la Buick de Joe" qui saurait toujours où se trouve la voiture.

Answer 5

Vous avez pratiquement répondu à votre propre question. Je ne crois pas que la spécification JavaBean mentionne quoi que ce soit à propos de l'immuabilité, pourtant les JavaBeans sont le pain et le beurre de nombreux frameworks Java.