oggetti immutabili .net

Question

voglio rispettare la mia base di codice regola immutabile con i seguenti test di

[TestFixture] 
public class TestEntityIf 
{ 
    [Test] 
    public void IsImmutable() 
    { 
     var setterCount = 
      (from s in typeof (Entity).GetProperties(BindingFlags.Public | BindingFlags.Instance) 
      where s.CanWrite 
      select s) 
       .Count(); 

     Assert.That(setterCount == 0, Is.True, "Immutable rule is broken"); 
    } 
} 

Passa per:

public class Entity 
{ 
    private int ID1; 
    public int ID 
    { 
     get { return ID1; } 
    } 
} 

ma non lo fa per questo:

public class Entity 
{ 
    public int ID { get; private set; } 
} 

E qui va la domanda "WTF?"

Answer 1

Una piccola modifica alle risposte pubblicate altrove. Quanto segue restituirà un valore diverso da zero se esiste almeno una proprietà con un setter protetto o pubblico. Notare il controllo per GetSetMethod che restituisce null (nessun setter) e il test per IsPrivate (cioè non pubblico o protetto) piuttosto che IsPublic (solo pubblico).

var setterCount = 
      (from s in typeof(Entity).GetProperties(
       BindingFlags.Public 
       | BindingFlags.NonPublic 
       | BindingFlags.Instance) 
      where 
       s.GetSetMethod(true) != null // setter available 
       && (!s.GetSetMethod(true).IsPrivate) 
      select s).Count(); 

Tuttavia, come pointed out in Daniel Brückner's answer, il fatto che una classe non ha property setter pubblicamente visibili è necessaria, ma non sufficiente per la classe da considerare immutabile.

Answer 2

Sicuramente è il tuo private set nel secondo.

Nel primo, un'istanza della classe Entity può avere la proprietà ID1 scritta da una classe esterna.

In quest'ultimo, il setter è privato alla classe stessa e così può essere chiamato solo dall'interno Entity (vale a dire che il proprio costruttore/inizializzazione)

Prendere la private dal vostro setter nel secondo e dovrebbe passare

Answer 3

Penso che la ragione è che CanWrite dice che restituisce true se c'è un setter. Un setter privato è anche un setter.

Quello che mi sorprende un po 'è che il primo passa, in quanto ha un setter pubblico, quindi a meno che non sia ancora troppo basso su cafeine, il settercount è 1 quindi l'asserzione dovrebbe fallire. Entrambi dovrebbero fallire, dato che CanWrite restituisce semplicemente la verità per entrambi. (e la query linq richiama semplicemente proprietà pubbliche, incluso l'ID, poiché è pubblica)

(modifica) Ora vedo che hai cambiato il codice della prima classe, quindi non ha più un setter.

Quindi la tua ipotesi è che CanWrite guardi ai metodi di accesso al metodo setter, non è così. Si dovrebbe fare:

var setterCount = 
      (from s in typeof (Entity).GetProperties(BindingFlags.Public | BindingFlags.Instance) 
      where s.GetSetMethod().IsPublic 
      select s) 
       .Count(); 

Answer 4

Il problema è, che la proprietà è pubblica - a causa del getter pubblico - ed è scrivibile - a causa del setter privato. Dovrai affinare il tuo test.

Inoltre, desidero aggiungere che non è possibile garantire l'immutabilità in questo modo poiché è possibile modificare i dati privati ​​all'interno dei metodi. Per garantire l'immutabilità, è necessario verificare che tutti i campi siano dichiarati in sola lettura e che non vi siano proprietà autoattive.

public static Boolean IsImmutable(this Type type) 
{ 
    const BindingFlags flags = BindingFlags.Instance | 
           BindingFlags.NonPublic | 
           BindingFlags.Public; 

    return type.GetFields(flags).All(f => f.IsInitOnly); 
} 

public static Boolean IsImmutable(this Object @object) 
{ 
    return (@object == null) || @object.GetType().IsImmutable(); 
} 

Con questo metodo di estensione si può facilmente verificare tipi

typeof(MyType).IsImmutable() 

e le istanze

myInstance.IsImmutable() 

per la loro immutabilità.

Note

• Guardando campi di istanza permette di avere le proprietà scrivibili, ma assicura che ora ci sono campi che possono essere modificati.
• Le proprietà di implementazione automatica non supereranno il test di immutabilità come previsto a causa del campo di backing privato e anonimo.
• È ancora possibile modificare i campi readonly utilizzando la riflessione.
• Forse si dovrebbe controllare che anche i tipi di tutti i campi siano immutabili, perché questi oggetti appartengono allo stato.
• Questo non può essere eseguito con un semplice FiledInfo.FieldType.IsImmutable() per tutti i campi a causa di possibili cicli e poiché i tipi di base sono modificabili.

Answer 5

Probabilmente necessario chiamare

propertyInfo.GetSetMethod().IsPublic 

perché il set-metodo e il metodo get-non hanno lo stesso modificatore di accesso, non si può contare sul PropertyInfo stesso.

var setterCount = 
     (from s in typeof (Entity).GetProperties(
      BindingFlags.Public 
      | BindingFlags.NonPublic 
      | BindingFlags.Instance) 
     where 
      s.GetSetMethod() != null  // public setter available 
     select s) 

Answer 6

Se ho capito bene, vuoi che Entity sia immutabile. Se è così, allora il test deve essere modificato in

var setterCount = (from s in typeof(string).GetProperties(BindingFlags.Public | BindingFlags.Instance).Select(p => p.GetSetMethod()) 
    where s != null && s.IsPublic 
    select s).Count(); 

Assert.That(setterCount == 0, Is.True, "Immutable rule is broken"); 

Answer 7

suggerisco un cambiamento nella condizione proprietà per:

s.CanWrite && s.GetSetMethod().IsPublic 

Answer 8

Hai provato a eseguire il debug per vedere quali proprietà la cui proprietà CanWrite è vero vengono restituiti dalla query LINQ? Apparentemente, sta raccogliendo cose che non ti aspetti. Con questa conoscenza, puoi rendere la tua query LINQ più selettiva per funzionare nel modo desiderato. Inoltre, sono d'accordo con @Daniel Bruckner che la tua classe non è completamente modificabile a meno che i campi non siano anche di sola lettura. Il chiamante può chiamare un metodo o utilizzare un getter che può modificare internamente i campi privati ​​che vengono esposti pubblicamente come readonly via Getter e ciò infrange la regola immutabile, sorprende il cliente e causa problemi. Le operazioni su oggetti mutabili non dovrebbero avere effetti collaterali.