Best practice Restituzione di oggetto di sola lettura

Ho una domanda sulle "migliori pratiche" su OOP in C # (ma in qualche modo si applica a tutte le lingue).

Prendi in considerazione la possibilità di avere una classe di libreria con un oggetto che deve essere esposto al pubblico, ad esempio tramite l'accesso alla proprietà, ma non vogliamo che il pubblico (le persone che usano questa classe di libreria) lo cambi.

class A
{
    // Note: List is just example, I am interested in objects in general.
    private List<string> _items = new List<string>() { "hello" }

    public List<string> Items
    {
        get
        {
            // Option A (not read-only), can be modified from outside:
            return _items;

            // Option B (sort-of read-only):
            return new List<string>( _items );

            // Option C, must change return type to ReadOnlyCollection<string>
            return new ReadOnlyCollection<string>( _items );
        }
    }
}

Ovviamente l'approccio migliore è "opzione C", ma pochissimi oggetti hanno la variante ReadOnly (e certamente nessuna classe definita dall'utente ce l'ha).

Se tu fossi l'utente di classe A, ti aspetteresti modifiche a

List<string> someList = ( new A() ).Items;

propagarsi all'oggetto originale (A)? O va bene restituire un clone purché sia ​​stato scritto in commenti / documentazione? Penso che questo approccio al clone potrebbe portare a bug piuttosto difficili da rintracciare.

Ricordo che in C ++ potevamo restituire oggetti const e potevi chiamare solo metodi contrassegnati come const su di esso. Immagino che non ci sia tale caratteristica / modello nel C #? In caso contrario, perché non dovrebbero includerlo? Credo che si chiama const correttezza.

Ma ancora una volta la mia domanda principale riguarda "cosa ti aspetteresti" o come gestire l'opzione A vs B.

Oltre alla risposta di @ Jesse, che è la migliore soluzione per le collezioni: l'idea generale è quella di progettare la tua interfaccia pubblica di A in modo che ritorni solo

• tipi di valore (come int, double, struct)

• oggetti immutabili (come "stringa" o classi definite dall'utente che offrono solo metodi di sola lettura, proprio come la tua classe A)

• (solo se necessario): copie dell'oggetto, come dimostra la tua "Opzione B"

IEnumerable<immutable_type_here> è immutabile da solo, quindi questo è solo un caso speciale di quanto sopra.

Si noti inoltre che si dovrebbe programmare su interfacce e, in generale, ciò che si desidera restituire da quella proprietà è un IEnumerable<string>. A List<string>è un po 'no-no perché è generalmente mutevole e andrò così lontano a dire che ReadOnlyCollection<string>come un implementatore di ICollection<string>sentirsi come se violasse il Principio di Sostituzione di Liskov.

Ho riscontrato un problema simile un po 'indietro e sotto era la mia soluzione, ma funziona davvero solo se controlli anche la libreria:

Inizia con la tua lezione A

public class A
{
    private int _n;
    public int N
    {
        get { return _n; }
        set { _n = value; }
    }
}

Quindi ricava un'interfaccia da questo con solo la porzione get delle proprietà (e tutti i metodi di lettura) e disponi di un attrezzo che

public interface IReadOnlyA
{
    public int N { get; }
}
public class A : IReadOnlyA
{
    private int _n;
    public int N
    {
        get { return _n; }
        set { _n = value; }
    }
}

Quindi, naturalmente, quando si desidera utilizzare la versione di sola lettura, è sufficiente un semplice cast. Questo è proprio ciò che la soluzione C è, in realtà, ma ho pensato di offrire il metodo con cui l'ho raggiunto

Per chiunque trovi questa domanda e sia comunque interessato alla risposta, ora c'è un'altra opzione che sta esponendo ImmutableArray<T>. Questi sono alcuni punti per cui penso che sia meglio allora IEnumerable<T>o ReadOnlyCollection<T>:

• afferma chiaramente che è immutabile (API espressiva)
• afferma chiaramente che la raccolta è già formata (in altre parole non è inizializzata pigramente ed è OK per iterarla più volte)
• se il conteggio degli oggetti è noto, non nasconde quel knowlegde come IEnumerable<T>fa
• poiché il cliente non sa quale sia l'implementazione IEnumerableo IReadOnlyCollectnon può presumere che non cambi mai (in altre parole, non vi è alcuna garanzia che gli articoli di una collezione non siano stati cambiati mentre il riferimento a quella collezione rimane invariato)

Inoltre, se l'APi dovesse notificare al cliente eventuali cambiamenti nella raccolta, esponerei un evento come membro separato.

Si noti che non sto dicendo che IEnumerable<T>è male in generale. Lo userei ancora quando si passa la raccolta come argomento o si restituisce una raccolta inizializzata pigramente (in questo caso particolare ha senso nascondere il conteggio degli oggetti perché non è ancora noto).