Objet immuable

On parle parfois d'immuabilité de certains champs d'un objet. Cela signifie qu'il est impossible de modifier ces parties de l'état de l'objet, même si d'autres parties peuvent être modifiées ( immuabilité faible ). Si tous les champs sont immuables, l'objet est immuable. Si l'objet entier ne peut être étendu par une autre classe, il est dit fortement immuable . Ceci peut, par exemple, permettre d'imposer explicitement certaines invariances concernant la constance de certaines données de l'objet tout au long de sa durée de vie. Dans certains langages, cela se fait à l'aide d'un mot-clé (par exemple consten C++ , finalen Java ) qui désigne le champ comme immuable. D'autres langages fonctionnent à l'inverse : en OCaml , les champs d'un objet ou d'un enregistrement sont immuables par défaut et doivent être explicitement marqués mutablecomme tels.

Dans la plupart des langages orientés objet , les objets peuvent être référencés par des références . Java , C++ , C# , VB.NET et de nombreux langages de script , tels que Perl , Python et Ruby , en sont des exemples . Dans ce cas, il est important de savoir si l'état d'un objet peut varier lorsque des objets sont partagés par référence.

S'il est établi qu'un objet est immuable, il est préférable d'en créer une référence plutôt que de le copier intégralement. Ceci permet d'économiser de la mémoire en évitant la duplication des données et les appels aux constructeurs et destructeurs ; cela peut également améliorer la vitesse d'exécution.

La technique de copie par référence est beaucoup plus difficile à mettre en œuvre pour les objets mutables, car toute modification apportée à une référence par un utilisateur est répercutée sur tous les autres utilisateurs. Si ce comportement n'est pas souhaité, il peut s'avérer complexe de les informer et d'obtenir leur réaction appropriée. Dans ce cas, la copie défensive de l'objet entier plutôt que de la référence constitue généralement une solution simple, mais coûteuse. Le modèle observateur offre une alternative pour gérer les modifications apportées aux objets mutables.

La technique de copie à l'écriture (COW) combine les avantages des objets mutables et immuables et est prise en charge directement par la quasi-totalité du matériel moderne. Grâce à cette technique, lorsqu'un utilisateur demande au système de copier un objet, celui-ci crée simplement une nouvelle référence pointant toujours vers le même objet. Dès qu'un utilisateur tente de modifier l'objet via cette référence, le système en effectue une copie réelle, y applique la modification et met à jour la référence pour qu'elle pointe vers la nouvelle copie. Les autres utilisateurs ne sont pas affectés, car ils continuent de faire référence à l'objet original. Ainsi, avec la COW, tous les utilisateurs semblent disposer d'une version mutable de leurs objets, même si, lorsqu'ils ne les modifient pas, les avantages des objets immuables en termes d'économie d'espace et de rapidité sont préservés. La copie à l'écriture est courante dans les systèmes de mémoire virtuelle car elle permet d'économiser de l'espace mémoire tout en assurant une gestion correcte des actions des applications.

L'utilisation systématique de références plutôt que de copies d'objets identiques est appelée intérim . Si l'intérim est utilisé, deux objets sont considérés comme égaux si et seulement si leurs références, généralement représentées par des pointeurs ou des entiers, sont identiques. Certains langages implémentent cela automatiquement : par exemple, Python intérime automatiquement les chaînes de caractères courtes . Si l'algorithme d'intérim garantit cette intérim dans tous les cas possibles, la comparaison d'objets se réduit à la comparaison de leurs pointeurs, ce qui représente un gain de vitesse considérable dans la plupart des applications. (Même si l'algorithme n'est pas exhaustif, il existe toujours la possibilité d'une optimisation rapide lorsque les objets sont égaux et utilisent la même référence.) L'intérim est généralement utile uniquement pour les objets immuables.

Les objets immuables sont utiles dans les applications multithread. Plusieurs threads peuvent manipuler des données représentées par des objets immuables sans craindre que ces données ne soient modifiées par d'autres threads. Les objets immuables sont donc considérés comme plus sûrs pour les threads que les objets mutables.

L'immuabilité n'implique pas que l'objet stocké en mémoire soit inaltérable. Il s'agit plutôt d'une construction de compilation indiquant ce qu'un programmeur peut faire via l'interface normale de l'objet, et non pas nécessairement ce qu'il peut absolument faire (par exemple, en contournant le système de types ou en violant la cohérence des constantes en C ou C++ ).

En Python , Java et dans le .NET Framework , les chaînes de caractères sont des objets immuables. Java et le .NET Framework proposent des versions mutables de chaînes de caractères. En Java , il s'agit StringBufferde `string` et StringBuilder`string` (versions mutables de Java Python 3 propose une variante mutable de chaînes de caractères (octets), nommée `string` bytearray.

De plus, toutes les classes d'encapsulation primitives en Java sont immuables.

Des modèles similaires sont l' interface immuable et de programmation purement fonctionnels, il n'est pas possible de créer des objets mutables sans étendre le langage (par exemple via une bibliothèque de références mutables ou une interface de fonction étrangère ), donc tous les objets sont immuables.

package Immutable ; use Moo ;a valeur => ( est => 'ro' , # lecture seule par défaut => 'data' , # peut être surchargé en fournissant au constructeur # une valeur : Immutable->new(valeur => 'autre chose'); );1 ;

package Immutable ; use strict ; use warnings ; use base qw(Class::Accessor) ; # créer des accesseurs en lecture seule __PACKAGE__ -> mk_ro_accessors ( qw(value) ); use Hash::Util 'lock_hash' ;sub new { my $class = shift ; return $class if ref ( $class ); die "Les arguments de new doivent être des paires clé => valeur " unless ( @_ % 2 == 0 ); my %defaults = ( value => 'data' , ); my $obj = { %defaults , @_ , }; bless $obj , $class ; # empêcher la modification des données de l'objet lock_hash %$obj ; } 1 ;

package Immutable ; use strict ; use warnings ; use Hash::Util 'lock_hash' ;sub new { my $class = shift ; return $class if ref ( $class ); die "Les arguments de new doivent être des paires clé => valeur " unless ( @_ % 2 == 0 ); my %defaults = ( value => 'data' , ); my $obj = { %defaults , @_ , }; bless $obj , $class ; # empêcher la modification des données de l'objet lock_hash %$obj ; }# sous - objet d'accès en lecture seule { my $self = shift ; if ( my $new_value = shift ) { # tentative de définition d'une nouvelle valeur die "Cet objet ne peut pas être modifié " ; } else { return $self -> { value } } } 1 ;

classe BlogData en lecture seule { public string $title ;Statut public $statut ;public function __construct ( string $title , Status $status ) { $this -> title = $title ; $this -> status = $status ; } }

from typing import Any , NoReturnclasse ImmutablePoint : Une classe immuable avec deux attributs 'x' et 'y'."""__slots__ : liste [ str ] = [ "x" , "y" ]def __setattr__ ( self , * args : tuple [ Any , ... ]) -> NoReturn : raise TypeError ( "Impossible de modifier une instance immuable." )__delattr__ : Callable [[ Tuple [ Any , ... ]], NoReturn ] = __setattr__def __init__ ( self , x : int , y : int ) -> None : # On ne peut plus utiliser self.value = value pour stocker les données de l'instance # il faut donc appeler explicitement la superclasse super () .__ setattr__ ( "x" , x ) super () .__ setattr__ ( "y" , y )