Fabbrica statica vs fabbrica come singleton

In alcuni dei miei codici, ho una fabbrica statica simile a questa:

public class SomeFactory {

    // Static class
    private SomeFactory() {...}

    public static Foo createFoo() {...}

    public static Foo createFooerFoo() {...}
}

Durante una revisione del codice, è stato proposto che questo dovesse essere un singleton e iniettato. Quindi, dovrebbe apparire così:

public class SomeFactory {

    public SomeFactory() {}

    public Foo createFoo() {...}

    public Foo createFooerFoo() {...}
}

Alcune cose da evidenziare:

• Entrambe le fabbriche sono apolidi.
• L'unica differenza tra i metodi sono i loro ambiti (istanza vs statica). Le implementazioni sono le stesse.
• Foo è un bean che non ha un'interfaccia.

Gli argomenti che ho avuto per diventare statico sono stati:

• La classe è senza stato, pertanto non è necessario creare un'istanza
• Sembra più naturale poter chiamare un metodo statico piuttosto che dover istanziare una fabbrica

Gli argomenti per la fabbrica come singleton erano:

• È bello iniettare tutto
• Nonostante l'apolidia della fabbrica, i test sono più facili con l'iniezione (facile da deridere)
• Dovrebbe essere deriso durante il test del consumatore

Ho alcuni seri problemi con l'approccio singleton poiché sembra suggerire che nessun metodo dovrebbe mai essere statico. Sembra anche suggerire che programmi di utilità come quelli StringUtilsdovrebbero essere avvolti e iniettati, il che sembra sciocco. Infine, implica che dovrò deridere la fabbrica ad un certo punto, il che non sembra giusto. Non riesco a pensare a quando dovrei prendere in giro la fabbrica.

Cosa pensa la comunità? Anche se non mi piace l'approccio singleton, non mi sembra di avere un argomento terribilmente forte contro di esso.

Perché dovresti separare la tua fabbrica dal tipo di oggetto che crea?

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

Questo è ciò che Joshua Bloch descrive come il suo Articolo 1 a pagina 5 del suo libro "Efficace Java". Java è abbastanza dettagliato senza aggiungere ulteriori classi, singleton e quant'altro. Ci sono alcuni casi in cui ha senso una classe di fabbrica separata, ma sono pochi e lontani tra loro.

Per parafrasare l'articolo 1 di Joshua Bloch, diversamente dai costruttori, i metodi statici di fabbrica possono:

• Hanno nomi in grado di descrivere tipi specifici di creazione di oggetti (Bloch utilizza probablePrime (int, int, Random) come esempio)
• Restituisce un oggetto esistente (pensa: peso mosca)
• Restituisce un sottotipo della classe originale o un'interfaccia implementata
• Riduci la verbosità (specificando i parametri di tipo - vedi Bloch per esempio)

svantaggi:

• Le classi senza un costruttore pubblico o protetto non possono essere sottoclassate (ma puoi usare costruttori protetti e / o Articolo 16: favorire la composizione sull'eredità)
• I metodi statici di fabbrica non si distinguono dagli altri metodi statici (utilizzare un nome standard come of () o valueOf ())

Davvero, dovresti portare il libro di Bloch al tuo revisore del codice e vedere se tutti e due siete d'accordo con lo stile di Bloch.

Appena al di sopra della mia testa, ecco alcuni dei problemi con la statica in Java:

• i metodi statici non giocano secondo le "regole" OOP. Non puoi forzare una classe a implementare metodi statici specifici (per quanto ne so). Quindi non puoi avere più classi che implementano lo stesso insieme di metodi statici con le stesse firme. Quindi sei bloccato con uno di quello che stai facendo. Non puoi nemmeno sottoclassare una classe statica. Quindi nessun polimorfismo, ecc.

• poiché i metodi non sono oggetti, i metodi statici non possono essere passati e non possono essere utilizzati (senza fare una tonnellata di codice di boilerplate), tranne per il codice che è strettamente collegato a loro - il che rende altamente il codice client accoppiati. (Per essere onesti, questo non è solo colpa della statica).

• i campi statici sono abbastanza simili ai globi globali

Hai nominato:

Ho alcuni seri problemi con l'approccio singleton poiché sembra suggerire che nessun metodo dovrebbe mai essere statico. Sembra anche suggerire che utilità come StringUtils dovrebbero essere racchiuse e iniettate, il che sembra sciocco. Infine, implica che dovrò deridere la fabbrica ad un certo punto, il che non sembra giusto. Non riesco a pensare a quando dovrei prendere in giro la fabbrica.

Il che mi rende curioso di chiederti:

• quali sono secondo te i vantaggi dei metodi statici?
• credi che StringUtilssia progettato e implementato correttamente?
• perché pensi che non dovrai mai deridere la fabbrica?

Penso che l'applicazione che stai costruendo debba essere abbastanza semplice, altrimenti sei relativamente all'inizio del suo ciclo di vita. L'unico altro scenario a cui riesco a pensare dove non avresti già avuto problemi con la tua statica è se sei riuscito a limitare le altre parti del codice che conoscono la tua Fabbrica a uno o due posti.

Immagina che la tua Applicazione si evolva e ora in alcuni casi devi produrre una FooBar(sottoclasse di Foo). Ora devi esaminare tutti i punti del codice che conoscono il tuo SomeFactorye scrivere una sorta di logica che guarda someConditione chiama SomeFactoryo SomeOtherFactory. In realtà, guardando il tuo codice di esempio, è peggio di così. Intendi semplicemente aggiungere un metodo dopo l'altro per creare Foos diversi e tutto il codice del tuo client deve verificare una condizione prima di capire quale Foo creare. Ciò significa che tutti i clienti devono avere una conoscenza intima di come funziona la tua fabbrica e tutti devono cambiare ogni volta che è necessario (o rimosso!) Un nuovo Foo.

Ora immagina se hai appena creato un IFooFactoryche fa un IFoo. Ora, produrre una sottoclasse diversa o persino un'implementazione completamente diversa è un gioco da ragazzi: basta alimentare la giusta IFooFactory più in alto nella catena e poi quando il client lo ottiene, chiama gimmeAFoo()e otterrà il giusto foo perché ha ottenuto la fabbrica giusta .

Forse ti starai chiedendo come si svolge nel codice di produzione. Per darvi un esempio dalla base di codice su cui sto lavorando che inizia a stabilizzarsi dopo poco più di un anno di progetti di avviamento, ho un sacco di fabbriche che vengono utilizzate per creare oggetti di dati di domande (sono qualcosa come modelli di presentazione ). Ho QuestionFactoryMapfondamentalmente un hash per cercare quale factory di domande usare quando. Quindi, per creare un'applicazione che pone domande diverse, ho inserito diverse fabbriche nella mappa.

Le domande possono essere presentate in Istruzioni o Esercizi (che implementano entrambi IContentBlock), in modo che ciascuno InstructionsFactoryo ExerciseFactoryottenga una copia di QuestionFactoryMap. Quindi, le varie fabbriche di Istruzioni ed Esercizi vengono consegnate alle ContentBlockBuilderquali mantiene di nuovo un hash di cui utilizzare quando. E poi quando l'XML viene caricato, ContentBlockBuilder richiama la Fabbrica di Esercizi o Istruzioni fuori dall'hash e glielo chiede createContent(), quindi la Fabbrica delega la costruzione delle domande a qualsiasi cosa estragga dalla sua QuestionFactoryMap interna in base a ciò si trova in ciascun nodo XML rispetto all'hash. Sfortunatamente , quella cosa è un BaseQuestionanziché unIQuestion, ma questo dimostra che anche quando stai attento al design puoi commettere errori che possono perseguitarti.

Il tuo intestino ti sta dicendo che queste statistiche ti faranno del male, e sicuramente ce ne sono molte in letteratura per sostenere il tuo intestino. Non perderai mai avendo l'iniezione delle dipendenze che finisci per usare solo per i tuoi test di unità (non che io creda che se costruisci un buon codice che non ti ritroverai ad usarlo più di quello), ma la statica può distruggere completamente la tua abilità per modificare rapidamente e facilmente il tuo codice. Quindi perché andarci?