Classificare con membri mutabili durante la creazione ma immutabili in seguito

Ho un algoritmo che crea una raccolta di oggetti. Questi oggetti sono mutabili durante la creazione, poiché iniziano con pochissimo, ma poi vengono popolati con dati in luoghi diversi all'interno dell'algoritmo.

Una volta completato l'algoritmo, gli oggetti non devono mai essere modificati, tuttavia vengono consumati da altre parti del software.

In questi scenari, è buona norma disporre di due versioni della classe, come descritto di seguito?

• Il mutevole viene quindi creato dall'algoritmo
• Al completamento dell'algoritmo, i dati vengono copiati in oggetti immutabili che vengono restituiti.

Puoi forse usare il modello del costruttore . Utilizza un oggetto 'builder' separato con lo scopo di raccogliere i dati necessari e quando tutti i dati vengono raccolti crea l'oggetto reale. L'oggetto creato può essere immutabile.

Un modo semplice per raggiungere questo obiettivo sarebbe avere un'interfaccia che consenta di leggere le proprietà e chiamare solo i metodi di sola lettura e una classe che implementa quell'interfaccia che consente anche di scrivere quella classe.

Il tuo metodo che lo crea, si occupa del primo e quindi restituisce il secondo fornendo solo un'interfaccia di sola lettura con cui interagire. Ciò non richiederebbe alcuna copia e ti consentirà di mettere a punto facilmente i comportamenti che desideri siano disponibili per il chiamante rispetto al creatore.

Prendi questo esempio:

public interface IPerson 
{
    public String FirstName 
    {
        get;
    }

    public String LastName 
    {
        get;
    }
} 

public class PersonImpl : IPerson 
{
    private String firstName, lastName;

    public String FirstName 
    {
        get { return firstName; }
        set { firstName = value; }
    }

    public String LastName 
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

class Factory 
{
    public IPerson MakePerson() 
    {
        PersonImpl person = new PersonImpl();
        person.FirstName = 'Joe';
        person.LastName = 'Schmoe';
        return person;
    }
}

L'unico svantaggio di questo approccio è che si potrebbe semplicemente lanciarlo nella classe di implementazione. Se fosse una questione di sicurezza, l'utilizzo di questo approccio non è sufficiente. Per ovviare a questo problema, è possibile creare una classe di facciata per avvolgere la classe mutabile, che presenta semplicemente un'interfaccia con cui il chiamante lavora e che non può avere accesso all'oggetto interno.

In questo modo, nemmeno il casting ti aiuterà. Entrambi possono derivare dalla stessa interfaccia di sola lettura, ma il cast dell'oggetto restituito ti darà solo la classe Facade, che è immutabile in quanto non cambia lo stato sottostante della classe mutabile avvolta.

Vale la pena ricordare che questo non segue la tendenza tipica in cui un oggetto immutabile viene costruito una volta per tutte attraverso il suo costruttore. Comprensibilmente, potresti dover gestire molti parametri, ma dovresti chiederti se tutti questi parametri devono essere definiti in anticipo o se alcuni possono essere introdotti in un secondo momento. In tal caso, dovrebbe essere utilizzato un semplice costruttore con solo i parametri richiesti. In altre parole, non utilizzare questo modello se sta nascondendo un altro problema nel programma.

Puoi usare il modello Builder come dice @JacquesB, o in alternativa pensare perché in realtà questi tuoi oggetti devono essere mutabili durante la creazione?

In altre parole, perché il processo di creazione di questi deve essere diffuso nel tempo, anziché passare tutti i valori richiesti nel costruttore e creare istanze in una volta sola?

Perché il Builder potrebbe essere una buona soluzione per il problema sbagliato.

Se il problema è che si finisce con un costruttore lungo 10 parametri e si desidera mitigarlo costruendo l'oggetto a poco a poco, potrebbe indicare che il design è incasinato e questi 10 valori dovrebbero essere " bagged "/ raggruppati in alcuni oggetti ... o l'oggetto principale diviso in alcuni più piccoli ...

In tal caso, attenersi completamente all'immutabilità, solo migliorare il design.