Buona o cattiva pratica? Inizializzazione di oggetti in getter

Ho una strana abitudine sembra ... almeno secondo il mio collega. Abbiamo lavorato insieme su un piccolo progetto. Il modo in cui ho scritto le lezioni è (esempio semplificato):

[Serializable()]
public class Foo
{
    public Foo()
    { }

    private Bar _bar;

    public Bar Bar
    {
        get
        {
            if (_bar == null)
                _bar = new Bar();

            return _bar;
        }
        set { _bar = value; }
    }
}

Quindi, fondamentalmente, inizializzo qualsiasi campo quando viene chiamato un getter e il campo è ancora nullo. Ho pensato che questo avrebbe ridotto il sovraccarico non inizializzando nessuna proprietà che non fosse usata da nessuna parte.

ETA: Il motivo per cui l'ho fatto è che la mia classe ha diverse proprietà che restituiscono un'istanza di un'altra classe, che a sua volta ha anche proprietà con ancora più classi e così via. Chiamare il costruttore per la classe superiore significherebbe successivamente chiamare tutti i costruttori per tutte queste classi, quando non sono sempre tutte necessarie.

Vi sono obiezioni contro questa pratica, oltre alle preferenze personali?

AGGIORNAMENTO: ho preso in considerazione le diverse opinioni divergenti riguardo a questa domanda e seguirò la mia risposta accettata. Tuttavia, ora sono arrivato a una comprensione molto migliore del concetto e sono in grado di decidere quando usarlo e quando no.

Contro:

• Problemi di sicurezza del thread
• Non obbedire a una richiesta "setter" quando il valore passato è nullo
• Micro-ottimizzazioni
• La gestione delle eccezioni dovrebbe avvenire in un costruttore
• È necessario controllare il codice null in class '

Professionisti:

• Micro-ottimizzazioni
• Le proprietà non restituiscono mai null
• Ritardare o evitare di caricare oggetti "pesanti"

La maggior parte dei contro non è applicabile alla mia attuale libreria, tuttavia dovrei testare per vedere se le "micro-ottimizzazioni" stanno effettivamente ottimizzando qualcosa.

ULTIMO AGGIORNAMENTO:

Ok, ho cambiato la mia risposta. La mia domanda iniziale era se questa è una buona abitudine. E ora sono convinto che non lo sia. Forse lo userò ancora in alcune parti del mio codice attuale, ma non incondizionatamente e sicuramente non sempre. Quindi perderò la mia abitudine e ci penserò prima di usarlo. Grazie a tutti!

Quello che hai qui è una - ingenua - implementazione di "inizializzazione pigra".

Risposta breve:

L'uso dell'inizializzazione lenta incondizionatamente non è una buona idea. Ha i suoi posti ma bisogna prendere in considerazione gli impatti che questa soluzione ha.

Contesto e spiegazione:

Implementazione concreta:
diamo prima un'occhiata al tuo esempio concreto e perché considero ingenua la sua implementazione:

1. Infrange il Principio di Least Surprise (POLS) . Quando un valore viene assegnato a una proprietà, si prevede che questo valore venga restituito. Nella tua implementazione questo non è il caso di null:

   foo.Bar = null;
   Assert.Null(foo.Bar); // This will fail

2. Presenta alcuni problemi di threading: Due chiamanti foo.Barsu thread diversi possono potenzialmente ottenere due diverse istanze di Bare una di esse sarà senza una connessione Fooall'istanza. Tutte le modifiche apportate a tale Baristanza vengono perse silenziosamente.
   Questo è un altro caso di violazione di POLS. Quando si accede solo al valore memorizzato di una proprietà, si prevede che sia thread-safe. Mentre potresti sostenere che la classe semplicemente non è thread-safe - incluso il getter della tua proprietà - dovresti documentarlo correttamente poiché non è il caso normale. Inoltre, l'introduzione di questo problema non è necessaria, come vedremo tra poco.

In generale:
è ora il momento di esaminare l'inizializzazione lazy in generale: l'
inizializzazione lazy viene solitamente utilizzata per ritardare la costruzione di oggetti che richiedono molto tempo per essere costruiti o che richiedono molta memoria una volta costruita completamente.
Questa è una ragione molto valida per usare l'inizializzazione lazy.

Tuttavia, tali proprietà normalmente non hanno setter, il che elimina il primo problema indicato sopra.
Inoltre, Lazy<T>per evitare il secondo problema verrebbe utilizzata un'implementazione sicura per i thread, come per esempio.

Anche quando si considerano questi due punti nell'implementazione di una proprietà pigra, i seguenti punti sono problemi generali di questo modello:

1. La costruzione dell'oggetto potrebbe non avere esito positivo, causando un'eccezione da un getter di proprietà. Questa è ancora un'altra violazione di POLS e quindi dovrebbe essere evitata. Anche la sezione sulle proprietà nelle "Linee guida di progettazione per lo sviluppo di librerie di classi" afferma esplicitamente che i getter di proprietà non dovrebbero generare eccezioni:

   Evitare di generare eccezioni dai getter di proprietà.

   I getter di proprietà dovrebbero essere semplici operazioni senza alcuna condizione preliminare. Se un getter potrebbe generare un'eccezione, considerare la riprogettazione della proprietà come metodo.

2. Le ottimizzazioni automatiche da parte del compilatore sono danneggiate, vale a dire inline e previsione del ramo. Si prega di consultare la risposta di Bill K per una spiegazione dettagliata.

La conclusione di questi punti è la seguente:
Per ogni singola proprietà implementata pigramente, dovresti aver considerato questi punti.
Ciò significa che si tratta di una decisione a seconda del caso e che non può essere presa come una buona pratica generale.

Questo modello ha il suo posto, ma non è una buona pratica generale quando si implementano le classi. Non dovrebbe essere usato incondizionatamente , a causa dei motivi sopra indicati.

In questa sezione voglio discutere alcuni dei punti che altri hanno avanzato come argomenti per l'utilizzo incondizionato dell'inizializzazione:

1. Serializzazione:
   EricJ afferma in un commento:

   Un oggetto che può essere serializzato non avrà il suo contruttore invocato quando è deserializzato (dipende dal serializzatore, ma molti di quelli comuni si comportano così). Inserire il codice di inizializzazione nel costruttore significa che è necessario fornire supporto aggiuntivo per la deserializzazione. Questo modello evita quella codifica speciale.

   Esistono diversi problemi con questo argomento:

   1. La maggior parte degli oggetti non verrà mai serializzata. L'aggiunta di una sorta di supporto per esso quando non è necessario viola YAGNI .
   2. Quando una classe deve supportare la serializzazione, esistono modi per abilitarla senza una soluzione alternativa che non ha nulla a che fare con la serializzazione a prima vista.

2. Micro-ottimizzazione: il tuo argomento principale è che vuoi costruire gli oggetti solo quando qualcuno li accede effettivamente. Quindi stai effettivamente parlando di ottimizzare l'utilizzo della memoria.
   Non sono d'accordo con questo argomento per i seguenti motivi:

   1. Nella maggior parte dei casi, alcuni altri oggetti in memoria non hanno alcun impatto su nulla. I computer moderni hanno abbastanza memoria. Senza un caso di problemi reali confermati da un profiler, si tratta di un'ottimizzazione pre-matura e ci sono buone ragioni contro di essa.

   2. Riconosco il fatto che a volte questo tipo di ottimizzazione è giustificata. Ma anche in questi casi l'inizializzazione lenta non sembra essere la soluzione corretta. Ci sono due ragioni per discuterne:

      1. L'inizializzazione lenta potenzialmente danneggia le prestazioni. Forse solo marginalmente, ma come ha mostrato la risposta di Bill, l'impatto è maggiore di quanto si possa pensare a prima vista. Quindi questo approccio sostanzialmente scambia le prestazioni contro la memoria.
      2. Se si dispone di un progetto in cui è un caso di utilizzo comune utilizzare solo parti della classe, ciò suggerisce un problema con il progetto stesso: la classe in questione molto probabilmente ha più di una responsabilità. La soluzione sarebbe quella di dividere la classe in diverse classi più mirate.

È una buona scelta di design. Altamente raccomandato per il codice della libreria o le classi principali.

Viene chiamato da una "inizializzazione lenta" o "inizializzazione ritardata" ed è generalmente considerata da tutti una buona scelta progettuale.

Innanzitutto, se si inizializza nella dichiarazione di variabili o costruttore a livello di classe, quando l'oggetto viene costruito, si ha il sovraccarico di creare una risorsa che non potrà mai essere utilizzata.

In secondo luogo, la risorsa viene creata solo se necessario.

Terzo, eviti che la spazzatura raccolga un oggetto che non è stato usato.

Infine, è più semplice gestire le eccezioni di inizializzazione che possono verificarsi nella proprietà rispetto alle eccezioni che si verificano durante l'inizializzazione delle variabili a livello di classe o del costruttore.

Ci sono delle eccezioni a questa regola.

Per quanto riguarda l'argomento delle prestazioni del controllo aggiuntivo per l'inizializzazione nella proprietà "get", è insignificante. L'inizializzazione e l'eliminazione di un oggetto è un risultato più significativo rispetto a un semplice controllo del puntatore null con un salto.

Linee guida di progettazione per lo sviluppo di librerie di classi all'indirizzo http://msdn.microsoft.com/en-US/library/vstudio/ms229042.aspx

per quanto riguarda Lazy<T>

La Lazy<T>classe generica è stata creata esattamente per quello che vuole il poster, vedi Inizializzazione pigra su http://msdn.microsoft.com/en-us/library/dd997286(v=vs.100).aspx . Se si dispone di versioni precedenti di .NET, è necessario utilizzare il modello di codice illustrato nella domanda. Questo modello di codice è diventato così comune che Microsoft ha ritenuto opportuno includere una classe nelle ultime librerie .NET per semplificare l'implementazione del modello. Inoltre, se l'implementazione richiede la sicurezza del thread, è necessario aggiungerla.

Tipi di dati primitivi e classi semplici

Obvioulsy, non userete l'inizializzazione lazy per un tipo di dati primitivo o un uso di classe semplice come List<string>.

Prima di commentare Lazy

Lazy<T> è stato introdotto in .NET 4.0, quindi per favore non aggiungere ancora un altro commento riguardo a questa classe.

Prima di commentare le microottimizzazioni

Quando si creano librerie, è necessario considerare tutte le ottimizzazioni. Ad esempio, nelle classi .NET vedrai array di bit utilizzati per le variabili di classe booleane in tutto il codice per ridurre il consumo di memoria e la frammentazione della memoria, solo per nominare due "micro-ottimizzazioni".

Per quanto riguarda le interfacce utente

Non si utilizzerà l'inizializzazione lazy per le classi utilizzate direttamente dall'interfaccia utente. La settimana scorsa ho trascorso la maggior parte della giornata rimuovendo il caricamento lento di otto raccolte utilizzate in un modello di visualizzazione per caselle combinate. Ho un LookupManagerche gestisce il caricamento e la memorizzazione nella cache delle raccolte necessarie per qualsiasi elemento dell'interfaccia utente.

"Setter"

Non ho mai usato una proprietà set ("setter") per nessuna proprietà caricata in modo pigro. Pertanto, non lo permetteresti mai foo.Bar = null;. Se è necessario impostare, Barvorrei creare un metodo chiamato SetBar(Bar value)e non utilizzare l'inizializzazione lazy

collezioni

Le proprietà della raccolta di classi vengono sempre inizializzate quando dichiarate perché non devono mai essere nulle.

Classi complesse

Consentitemi di ripeterlo in modo diverso, usate l'inizializzazione lazy per classi complesse. Che di solito sono classi mal progettate.

infine

Non ho mai detto di farlo per tutte le classi o in tutti i casi. È una cattiva abitudine.

Consideri l'implementazione di tale modello usando Lazy<T>?

Oltre alla facile creazione di oggetti caricati in modo pigro, si ottiene la sicurezza del thread durante l'inizializzazione dell'oggetto:

• http://msdn.microsoft.com/en-us/library/dd642331.aspx

Come altri hanno già detto, carichi pigramente oggetti se sono veramente ricchi di risorse o ci vuole del tempo per caricarli durante i tempi di costruzione degli oggetti.

Penso che dipenda da cosa stai inizializzando. Probabilmente non lo farei per un elenco in quanto il costo di costruzione è piuttosto piccolo, quindi può andare nel costruttore. Ma se fosse un elenco precompilato, probabilmente non lo farei finché non fosse necessario per la prima volta.

Fondamentalmente, se il costo di costruzione supera il costo di fare un controllo condizionale su ogni accesso, allora pigro crearlo. In caso contrario, fallo nel costruttore.

Il rovescio della medaglia che posso vedere è che se vuoi chiedere se Bars è nullo, non lo sarebbe mai e creeresti l'elenco lì.

L'istanza / inizializzazione lenta è un modello perfettamente praticabile. Tieni presente, tuttavia, che, come regola generale, i consumatori della tua API non si aspettano che getter e setter impieghino tempo riconoscibile dal POV dell'utente finale (o falliscano).

Stavo solo per inserire un commento sulla risposta di Daniel, ma onestamente non penso che vada abbastanza lontano.

Anche se questo è un ottimo modello da utilizzare in determinate situazioni (ad esempio, quando l'oggetto viene inizializzato dal database), è un'abitudine ORRIBILE per entrare.

Una delle cose migliori di un oggetto è che offre un ambiente sicuro e affidabile. Il caso migliore è se crei il maggior numero possibile di campi "Final", riempiendoli tutti con il costruttore. Questo rende la tua classe abbastanza a prova di proiettile. Consentire la modifica dei campi tramite setter è un po 'meno, ma non è terribile. Per esempio:

classe SafeClass
{
    String name = "";
    Età intera = 0;

    public void setName (String newName)
    {
        assert (newName! = null)
        name = newName;
    } // segui questo schema per età
    ...
    public String toString () {
        String s = "La classe sicura ha nome:" + nome + "ed età:" + età
    }
}

Con il tuo modello, il metodo toString sarebbe simile al seguente:

    if (nome == null)
        getta nuovo IllegalStateException ("SafeClass è entrato in uno stato illegale! il nome è null")
    if (età == null)
        gettare nuovo IllegalStateException ("SafeClass è entrato in uno stato illegale! l'età è nulla")

    public String toString () {
        String s = "La classe sicura ha nome:" + nome + "ed età:" + età
    }

Non solo, ma hai bisogno di controlli null ovunque tu possa eventualmente usare quell'oggetto nella tua classe (fuori dalla tua classe è sicuro a causa del controllo null nel getter, ma dovresti usare principalmente i membri della tua classe all'interno della classe)

Anche la tua classe è perennemente in uno stato incerto, ad esempio se decidi di rendere quella classe una classe in letargo aggiungendo alcune annotazioni, come faresti?

Se si prende una decisione basata su una micro-optomizzazione senza requisiti e test, è quasi sicuramente una decisione sbagliata. In effetti, c'è davvero una buona possibilità che il tuo modello stia effettivamente rallentando il sistema anche nelle circostanze più ideali perché l'istruzione if può causare un errore di previsione del ramo sulla CPU che rallenterà molte molte molte più volte rispetto a assegnare semplicemente un valore nel costruttore a meno che l'oggetto che si sta creando non sia abbastanza complesso o provenga da un'origine dati remota.

Per un esempio del problema della previsione del brance (che stai riscontrando ripetutamente, quasi una volta sola), vedi la prima risposta a questa fantastica domanda: Perché è più veloce elaborare un array ordinato rispetto a un array non ordinato?

Vorrei solo aggiungere un altro punto a molti punti positivi fatti da altri ...

Il debugger valuterà ( per impostazione predefinita ) le proprietà quando passa attraverso il codice, il che potrebbe potenzialmente creare un'istanza Barprima di quanto accadrebbe normalmente eseguendo semplicemente il codice. In altre parole, il semplice atto di debug sta cambiando l'esecuzione del programma.

Questo può o meno essere un problema (a seconda degli effetti collaterali), ma è qualcosa di cui essere consapevoli.

Sei sicuro che Foo dovrebbe istanziare qualcosa?

A me sembra puzzolente (anche se non necessariamente sbagliato ) lasciare a Foo un'istanza per nulla. A meno che lo scopo esplicito di Foo non sia quello di essere una fabbrica, non dovrebbe istanziare i propri collaboratori, ma piuttosto farli iniettare nel suo costruttore .

Se comunque lo scopo di Foo di essere è creare istanze di tipo Bar, allora non vedo nulla di male nel farlo pigramente.