Quando usare [Pure] su un costruttore?

Sto imparando i contratti di codice in .NET e sto cercando di capire l'idea di costruttori puri. La documentazione relativa ai contratti di codice afferma:

Tutti i metodi chiamati all'interno di un contratto devono essere puri; cioè, non devono aggiornare alcuno stato preesistente. Un metodo puro è autorizzato a modificare oggetti che sono stati creati dopo l'entrata nel metodo puro.

E la PureAttributedocumentazione afferma:

Indica che un tipo o un metodo è puro, ovvero non apporta alcuna modifica dello stato visibile.

Capisco queste affermazioni quando si tratta di metodi, ma per quanto riguarda i costruttori? Supponiamo che tu abbia tenuto una lezione come questa:

public class Foo
{
    public int Value { get; set; }

    public Foo(int value) {
        this.Value = value;
    }
}

Questo costruttore ovviamente influenza lo stato del nuovo Foooggetto, ma non ha altri effetti collaterali (ad es. Non manipola nessuno dei parametri né chiama metodi non puri). È un candidato per [Pure]o no? Qual è il significato di posizionare un [Pure]attributo su un costruttore e quando dovrei farlo nel mio codice?

Decorare un metodo con [Pure]:

• Se il metodo non ha effetti collaterali. Ad esempio, se il metodo accede a un database e lo modifica o il suo risultato dipende dal database, non è puro.

• E se prevedi di usarlo nei contratti di codice. Ad esempio, se il metodo è puro , ma non hai intenzione di utilizzarlo nei contratti di codice, l'aggiunta non [Pure]avrebbe alcun vantaggio e non renderebbe il tuo codice più veloce.

Per quanto riguarda i costruttori, sembra che siano considerati puri in .NET e non necessitino di un attributo esplicito. Ho esaminato diversi costruttori nel sorgente .NET Framework, come ad esempio DateTime, e non hanno [Pure]attributi.

Suppongo che ciò avvenga per diversi motivi:

• Potrebbe essere troppo poco pratico dover scrivere un costruttore senza parametri con [Pure]attributo solo per poter usare la classe / struttura in un contratto.

• Alcuni, come ad esempio String, non hanno costruttori espliciti.

• I costruttori ricevono un trattamento speciale anche al di fuori dei contratti di codice; ad esempio, non è previsto che vengano generate eccezioni al loro interno .

• [Pure]è solo una convenzione che è qui per semplificarti la vita, ma non esiste un vero controllo statico per garantire che il metodo decorato con questo attributo sia puro. void DestroyDatabase()può essere decorato come puro e i contratti di codice non noteranno nulla di sbagliato.

  Attualmente non esiste alcun componente dei Contratti di codice che controlli se i metodi dichiarati puri siano effettivamente puri. Quindi, se un programmatore ha decorato un metodo con [Pure], si crede.

  ^{Dai contratti n. 5 del codice: purezza del metodo}

• .NET Framework stesso contiene costruttori che non sono puri. Ad esempio, List<T>(IEnumerable<T> collection)è in realtà impuro se il ciclo attraverso la raccolta ha effetti collaterali.

• I contratti gridano essere semplici. Posso facilmente immaginare un contratto del genere Contract.Requires(!string.IsNullOrEmpty(name)), quindi ci sono buone ragioni per dichiarare statico string.IsNullOrEmptypuro.

  D'altra parte, se hai bisogno di un oggetto StringBuilderper costruire la stringa, verificherai qualcosa chiamando un metodo di istanza della tua business class, probabilmente stai abusando dei contratti. Questo è anche il motivo per cui StringBuilder.ToStringnon è contrassegnato come puro, anche se potrebbe essere (vero?)

L'oggetto non può essere utilizzato fino a quando non viene costruito in questo caso. Pertanto il costruttore è puro. Se il costruttore chiamasse un altro codice o invocasse un delegato e l'altro codice modificasse la proprietà mutable, non sarebbe puro. Per essere più sicuri, è meglio rendere l'immobile immutabile.