L'immuabilité est-elle utile sur des applications non parallèles?

Question

J'aime le concept d'immutabilité, mais je me demande parfois, lorsqu'une application n'est pas supposée être parallèle, faut-il éviter de rendre les choses immuables?

Lorsqu'une application n'est pas multi-thread, vous n'êtes pas en proie à des problèmes d'état partagé, n'est-ce pas?

Ou l’immuabilité est-elle un concept comme la POO que vous utilisez ou non? Exclure les cas où quelque chose ne devrait pas être immuable en fonction de l'utilisation / des performances, etc.

Je suis confronté à cette question lorsque je rédige une application modérément volumineuse (peut-être 1 ou 2 lignes).

Answer 1

J'aime l'immuabilité parce que cela signifie que je n'ai pas à faire confiance au code des autres peuples pour ne pas déranger avec des objets qui devraient rester les mêmes.

Lorsque vous transmettez un objet à un autre composant tel qu'un List<T>, vous êtes à la merci de ce que fait ce composant. Ceci est particulièrement important lorsque vous renvoyez des collections en tant que propriétés.

public class Foo { 
  private List<Bar> _barList;
  public ICollection<Bar> BarList { get return _barList; } 
}

Rien n'empêche un consommateur de cette classe de nettoyer la collection de sous moi. Même changer le type de retour sur IEnumerable<Bar> n'est pas totalement sûr. Rien n'empêche un morceau de code mal écrit de renvoyer cela en <=> et d'appeler .Clear ().

Cependant, si je veux vraiment que la collection reste cohérente, je pourrais la réécrire comme suit

public class Foo {
  private ImmutableCollection<Bar> _barList;
  public ImmutableCollection<Bar> BarList { get { return _barList; } }
}

Maintenant, je suis sûr de ne pas avoir à faire confiance à un autre code pour utiliser ma classe de manière incorrecte. Ils ne peuvent pas tout gâcher.

Answer 2

J'aime l'avantage de l'immuabilité que vous devez valider une seule fois - lors de la création d'un objet. C'est un bonus énorme en fait.

Answer 3

L’un des principaux avantages de l’immuabilité est qu’il n’est pas nécessaire de suivre la propriété des objets immuables. Ils n'existent que tant que quelqu'un en a besoin, puis disparaissent dans le néant lorsqu'ils ne sont plus nécessaires. Bien que l’utilisation d’un ramasse-miettes signifie dans de nombreux cas qu’il n’est pas nécessaire d’écrire expressément du code traitant de la propriété des objets mutables (la plus grande exception étant ceux qui implémentent IDisposable), il est très souvent très difficile d’écrire le code correct dans lequel les objets qui ont l’état mutable n’ont pas un " propriétaire " clairement défini. La confusion concernant le propriétaire de l'état des objets mutables peut être une source très fréquente de bogues; Lorsque vous utilisez des objets immuables (à part quelques-uns qui implémentent List<T>), vous pouvez généralement ignorer les problèmes de propriété.

Un autre point à prendre en compte est qu’il est beaucoup plus facile de raisonner sur une référence modifiable à un objet sémantiquement immuable, ou une référence immuable sur un objet modifiable, que de raisonner sur une référence modifiable à un objet modifiable. Si une référence mutable à un objet mutable est définie, il peut souvent être difficile de savoir si la bonne approche pour mettre à jour un état consiste à simplement muter l'objet directement ou à copier son état dans un nouvel objet, à le muter et à mettre à jour la référence. Dans certains cas, il y aura des circonstances nécessitant chaque type d'opération (comme avec <=>, qui remplace parfois un tableau par un plus grand, mais effectue généralement les mises à jour sur place), mais une telle approche ne fonctionne que si le type conserve exclusivement contrôle sur les objets mutables en question. Il est souvent plus utile d'avoir une référence immuable à un type mutable (dans ce cas, le code peut exposer la référence, éventuellement via un wrapper en lecture seule, à d'autres objets qui souhaitent une & Quot; vue en direct & Quot; de son état) ou bien avoir une référence mutable à un objet qui est immuable ou, au minimum, ne sera jamais muté pendant la durée de vie de la référence.