Pour prendre un exemple simple, il s'agit d'un moyen bon marché de créer un objet "suffisamment immuable" (pour l'utiliser dans le threading, l'état, etc.). Mais aussi partout où le client doit simplement ne devrait pas besoin de l'attribuer, ou on ne peut pas lui faire confiance pour l'attribuer (correctement).
Un autre exemple pourrait être une liste :
public List<Foo> Items {get;private set;}
puisque nous pourrions appeler obj.Items.Add()
etc., mais nous rarement attribuer obj.Items = ...
. Cependant, cet exemple est entaché par la nécessité d'une initialisation explicite dans le constructeur, et XmlSerializer
déteste - pour être honnête pour les listes que j'utilise principalement :
private readonly List<Foo> items = new List<Foo>();
public List<Foo> Items {get { return items;}}
qui résout ces deux problèmes.
Autre exemple, le contraste :
private readonly int foo;
public int Foo {get{return foo;}}
vs
private readonly int foo;
public int Foo {get{return foo;} private set {foo=value;}}
ce modèle peut être utile dans la sérialisation, par exemple avec DataContractSerializer
(avec l'ajout de certains attributs), car de nombreux sérialiseurs rechercheront toujours des accesseurs privés. Cela nous évite d'avoir à décorer nos interne l'état ( foo
), mais donne le placage de la vie privée au set
.
En fin de compte, tout ce qui est peuvent être contournés et assignés via la réflexion, ainsi les privés set
n'a pour but que d'éviter accidentel des dommages aux données.