Interfacce "immutabili"

However, from the viewpoint of CalculatorClient, who talks to it only through the IOperationalInterface, it appears to be immutable and the Sum operation appears to be pure in the sense that it could not observe any side effects through that interface.

Qualunque cosa tu possa osservare attraverso l'interfaccia è irrilevante per il concetto di purezza. Se Sum ha registrato risultati in un file, sarebbe comunque impuro anche se non saresti in grado di osservare alcuna modifica attraverso l'interfaccia.

La purezza è una condizione molto strong. Se dici che qualcosa è puro, ti prenderò in parola e supporterò che non accadrà nulla di male se lo avrò eseguito da più thread, memorizzerò i risultati nella cache e lo chiamerò solo una volta per ogni dato insieme di input, o che posso chiamare 1.000.000 di volte senza esaurire gli handle di file del sistema operativo. Queste ipotesi possono ritorcersi contro quando si utilizza CalculatorImpl .

Non c'è niente di sbagliato nel partizionare le interfacce come te, ma dovresti essere preciso. La specifica che vuoi per IOperationalInterface è probabilmente più vicina a: "Il valore di ritorno di questi metodi deve dipendere solo dai loro argomenti, ma la loro esecuzione può avere effetti collaterali." Puoi essere più specifico sugli effetti collaterali e dire che i metodi non devono eseguire alcun tipo di I / O. Ma non direi che è puro, perché lo stai chiaramente usando in questo modo.

Sei quasi impiccato alle definizioni senza preoccuparti del perché ti interessi se una funzione è pura o meno. Una funzione pura dà più libertà al chiamante a spese delle restrizioni sull'implementatore. Una funzione con effetti collaterali offre maggiore libertà all'installatore a spese delle restrizioni sul chiamante.

Molti hanno familiarità con le restrizioni sull'implementatore di una funzione pura, ma molti non hanno familiarità con le libertà che concede al chiamante. Libera il chiamante per memorizzare i risultati nella cache e non chiamare la funzione una seconda volta. Libera il chiamante per creare tante copie dell'oggetto come vogliono, magari su thread differenti o anche su sistemi diversi, per velocizzare il calcolo. Libera il chiamante a non doversi preoccupare di mantenere l'oggetto in ambito, perché possono sempre ricreane uno identico in seguito.

Se non si concedono questi tipi di libertà al chiamante, non è utile etichettare un'interfaccia immutabile. Stai mettendo delle restrizioni sull'implementatore senza alcun beneficio commisurato al chiamante, quindi potresti anche rimuovere le restrizioni dell'implementatore.

L'implementazione non è chiaramente immutabile, quindi parliamo della "purezza" della funzione Sum .

Può avere senso parlare dell'implementazione, non dell'interfaccia. Ad esempio, cosa succede se ho creato una nuova implementazione dell'interfaccia con questa implementazione di Sum ?

public int Sum(int a, int b) {
    invocations++;
    if(invocations >= 1000)
    {
        return a + b + 1;
    }
    return a + b;
}

L'interfaccia non è cambiata, ma il metodo non è più "puro".

In un senso puramente tecnico, anche la tua ingenua implementazione non è pura perché alla fine invocations andrà in overflow e otterrai un'eccezione quando chiami Sum invece del risultato previsto.

Credo che quello che vuoi sia una variante di Design by Contract (le interfacce C # sono una versione povera di loro) . In C # potrebbe essere ottenuto tramite attributi personalizzati e un'estensione dell'analizzatore statico (ad esempio per Roslyn o ReSharper):

[Pure] //This is just a sample name, not to be confused with System.Diagnostics.Contracts.PureAttribute
interface IOperationalInterface
{
    int Sum(int a, int b);
}

L'estensione dell'analizzatore statico personalizzato dovrebbe quindi verificare se le implementazioni sono prive di effetti collaterali su tutti i metodi dell'interfaccia. Ciò potrebbe complicarsi a seconda del livello di garanzia che vorresti ottenere (ad esempio, semplicemente controllando che non ci siano operatori mutanti usati contro le catene di invocazione del metodo).

Se ritieni che questo approccio sia fattibile per il tuo scenario, allora considera la possibilità di controllare gli strumenti relativi al contratto esistenti per .NET (non funziona bene però):

JetBrains: link Microsoft: link