Fabbriche "Singleton", ok o cattive?

Question

Ho un sacco di fabbriche (astratte) e di solito vengono implementate come singleton.

Solitamente per la comodità di non dover passare attraverso strati che non hanno davvero alcun rapporto con l'utilizzo o la conoscenza di queste fabbriche.

maggior parte delle volte ho solo bisogno di prendere una decisione in fase di avvio del quale implementazione fabbrica il resto del programma in codice, forse attraverso qualche configurazione

sembra per esempio come

abstract class ColumnCalculationFactory { 
    private static ColumnCalculationFactory factory; 

public static void SetFactory(ColumnCalculationFactory f) { 
     factory = f; 
    } 

    public static void Factory() { 
     return factory; 
    } 

public IPercentCalculation CreatePercentCalculation(); 
public IAverageCalculation CreateAverageCalculation(); 
    .... 

} 

Someting fare odore di questo, solo che non sono sicuro di quello che - è forse più un disuised globale di un Singleton. Non è che ci siano davvero a essere una sola fabbrica a creare ColumnCalculations, anche se i miei programmi non ne hanno bisogno.

È considerato utile? Dovrei piuttosto inserirli in alcune classi (semi) globali di AppContext? Qualcos'altro (non sono ancora pronto per passare ad un contenitore IoC più grande, o ancora spring.net)?

Answer 1

Dipende molto da cosa stai facendo e dalla portata della tua applicazione. Se è solo un'app abbastanza piccola e non andrà mai oltre questo, allora il tuo approccio attuale potrebbe andar bene. Non esiste una pratica "migliore" universale per queste cose. Anche se non consiglierei l'uso di singleton per qualcosa di diverso dai metodi foglia stateless e/o le chiamate unidirezionali (ad esempio la registrazione), escludendolo "solo perché" è un singleton non è necessariamente la cosa giusta da fare.

Per qualcosa di diverso dal codice banale o prototipo, personalmente desidero utilizzare esplicitamente l'inversione del controllo con l'iniezione del costruttore, poiché significa che tutte le dipendenze sono state prese in considerazione e non si ottengono "sorprese". Il compilatore non ti permetterà di istanziare A senza B e B senza C. Singletons interrompe immediatamente queste relazioni - puoi istanziare A senza B e B senza C. Quando la chiamata da A a B avviene, otterrai un riferimento nullo eccezione.

Ciò è particolarmente fastidioso durante il test, poiché è necessario eseguire iterativamente all'indietro tramite errori di runtime. Quando esegui il test del codice, stai utilizzando l'API proprio come farebbe un altro codificatore, quindi è indicativo dei problemi di progettazione con questo approccio. L'iniezione del costruttore garantisce che questo non possa mai accadere - tutte le dipendenze sono dichiarate in anticipo. Il rovescio della medaglia con l'iniezione del costruttore è che la configurazione del tuo oggetto grafico è più complicata. Questo è mitigato attraverso l'uso di un contenitore IoC.

Immagino che quello che sto cercando di dire è che se sei arrivato al punto in cui stai prendendo in considerazione l'utilizzo di qualche tipo di oggetto di contesto e di un modello di registro, puoi anche dare un'occhiata ai contenitori IoC. Passare allo sforzo di rotolare la tua versione di mutt è probabilmente una perdita di tempo quando puoi usare un prodotto consolidato e gratuito come Autofac.

Answer 2

È considerata la migliore prassi?

Non vedo alcun problema: lei ha detto "i miei programmi non hanno bisogno di più", quindi il vostro attuare qualcosa di più flessibile/astratto potrebbe essere un caso di You Ain't Gonna Need It.

Answer 3

No, perché quello che stai facendo qui sta creando uno stato globale. Ci sono tutti i tipi di problemi con lo stato globale - tra cui, in primo luogo, una funzione dipende in modo piuttosto invisibile dal comportamento di altre funzioni. Se una funzione chiama un'altra funzione che dimentica di archiviare e ripristinare lo factory prima che finisca, allora hai un problema perché non puoi nemmeno recuperare il vecchio valore se non lo hai memorizzato da qualche parte. E devi aggiungere del codice per farlo (a giudicare dal tuo codice, direi che sei in una lingua con finally, che lascia ancora più spazio per errori). Inoltre, se si finisce con il codice che deve passare rapidamente tra due fabbriche per due sottooggetti, è necessario scrivere una chiamata al metodo in ogni punto: non è possibile memorizzare lo stato in ciascun sottooggetto (beh, è ​​possibile, ma in questo caso sconfiggi lo scopo dello stato globale [che, ammettiamolo, non è molto]).

Probabilmente ha più senso memorizzare il tipo di fabbrica come membro e passarlo al costruttore di nuovi oggetti che ne hanno bisogno (o crearne uno nuovo secondo necessità, ecc.). Ti dà anche un controllo migliore: puoi garantire che tutti gli oggetti costruiti dall'oggetto A passino attraverso lo stesso stabilimento o che tu offra metodi per scambiare le fabbriche.

Answer 4

Vorrei sconsigliarlo, perché rende molto difficile scrivere test di unità decenti per il codice che chiama queste fabbriche.

Misko Hevery ha uno nice article sul suo blog.

Answer 5

Avere pochi singletons è piuttosto tipico e di solito non è problematico: un sacco di singleton porta a qualche codice irritante.

Abbiamo appena attraversato una situazione in cui dovevamo testare le nostre classi pesantemente singleton. Il problema è che quando si prova la classe b, e si ottiene la classe c (un singleton), non si ha modo di deridere la classe c (Almeno EasyMock non ci permetterebbe di sostituire il metodo statico di fabbrica di una classe singleton.

Una semplice soluzione consiste nell'avere "setter" per tutti i tuoi singleton a scopo di test. Non proprio raccomandato.

Un'altra cosa che abbiamo provato era quella di avere una singola classe che contenesse tutti i singleton: un registro. Fare questo sta diventando piuttosto vicino all'iniezione di dipendenza che è quello che dovresti quasi sicuramente usare.

Oltre ai test, ho imparato molto tempo fa quando non ci sono mai e poi mai più di una istanza di un dato oggetto; nel prossimo giro ne vogliono spesso due, il che rende i singleton MOLTO meglio delle classi statiche - almeno è possibile aggiungere un parametro al getter di un singleton e restituire un secondo senza troppo refactoring (che sta facendo di nuovo ciò che fa DI).

In ogni caso, guarda DI, potresti essere davvero felice.

Answer 6

La cattiva forma di Singleton è quello che implementa l'equivalente del tuo metodo di fabbrica con:

return new CalculationFactory(); 

Questo è molto più difficile da stub, finta o avvolgere.

La versione che restituisce un oggetto creato altrove è molto meglio, anche se, come quasi tutto, può essere utilizzata in modo improprio o sovrautilizzata.