È meglio avere una classe factory separata rispetto ai metodi statici nella stessa classe. Vedi questa domanda .
Ma l'API standard utilizza entrambi gli approcci.
Fabbrica separata:
DatatypeFactory.newInstance().newXMLGregorianCalendar(...)
Metodi statici nella stessa classe:
Calendar.getInstance(...)
Perché è questo? In che caso, avere metodi statici sarebbe meglio che avere una fabbrica separata?
La fabbrica è probabilmente uno dei modelli più abusati. Le persone parlano sempre di come è possibile passare facilmente a un altro factory che genera classi diverse, ma di solito non si accorge che non è possibile farlo solo con la factory - è necessario anche un po 'di injection dependance!
L'overhead sembra piccolo: utilizza CalendarFactory.newInstance().newCalendar() anziché Calendar.getInstance() . Ma volevamo la fabbrica in primo luogo, così da poter passare facilmente alle fabbriche e cambiare il modo in cui gli oggetti sono costruiti. Possiamo farlo davvero qui? CalendarFactory.newInstance() è sempre la stessa funzione quindi restituirà sempre un oggetto factory costruito allo stesso modo, che creerà Calendar s nello stesso modo. Per modificare il processo di creazione Calendar , dobbiamo modificare CalendarFactory.newInstace o CalendarFactory.newCalendar . Come è meglio non dover cambiare Calendar.getInstance ?
Se vogliamo essere in grado di modificare facilmente il processo di creazione Calendar , abbiamo dovuto usare dependency injection: creare un oggetto CalendarFactory da qualche parte e passarlo. In questo modo possiamo controllare quale fabbrica usano i metodi che chiamiamo e gli oggetti che costruiamo.
Tuttavia, c'è un inconveniente a questo approccio: passare questo oggetto factory in giro comporta un notevole onere per il programmatore. I metodi richiedono degli argomenti extra - per l'intera catena di chiamate da dove viene creato il factory in cui viene utilizzato. Gli oggetti richiedono un campo aggiuntivo che è necessario fornire anche se non si utilizza alcun metodo che richiede quella fabbrica (in alternativa - è necessario ricordare se è stato fornito o meno, e verrà generata un'eccezione se il campo factory non è impostato. Ma questo espone l'implementazione in quanto costringe l'utente a sapere quali metodi richiedono l'impostazione del campo factory).
Dato che il sovraccarico qui è molto più grande di quello ingenuo, inutile uso della fabbrica, non possiamo applicare ciecamente il modello (OK, lo riprendo - puoi sempre applicare ciecamente il design modelli e troppi programmatori) e in realtà dobbiamo pensare. Abbiamo davvero bisogno di essere in grado di cambiare il processo di creazione Calendar dappertutto? Ne abbiamo abbastanza bisogno per introdurre tale onere sui programmatori?
Nel caso di Calendar di Java, la risposta era "no". Essere in grado di distinguere l'ora in modo diverso o rappresentarla in modo diverso nella memoria non è abbastanza utile per passare attorno a un oggetto CalendarFactory dappertutto.
Non è un singleton (ho vissuto una bugia ...). Ora sembra una convenzione di denominazione scadente.
Sembra la conevoluzione di Java per un singleton getInstance() , è ClassName.getClassName()
Puoi vederlo in Desktop.getDesktop() (java.awt).
Il getInstance() appartiene ai pattern di fabbrica, il che significa che Calendar è un factory.
Factory di solito iniziano con newXYZ () mentre un singleton di solito ha il metodo getinstance () .
Nel tuo esempio, DataTypeFactory è, in effetti, una fabbrica.
D'altra parte, Calendar è un singleton e come tale ha un metodo getInstance() .
Leggi altre domande sui tag architecture design-patterns