Devo utilizzare sempre metodi di factory static invece di costruttori?

Lettura Efficace di Java, sembra che ci siano molti vantaggi, e pochissimi svantaggi, nell'usare metodi di produzione statici. Con metodi factory statici In particolare mi riferisco alla seguenteDevo utilizzare sempre metodi di factory static invece di costruttori?

public class MyClass {  
    private MyClass() { ... }; 

    public static MyClass getInstance() { 
    return new A(); 
    }  
}

Da Effective Java:

Si noti che un metodo factory statico non è la stessa come il modello Factory Method dal Design Patterns [Gamma95, p. 107]. Il metodo factory statico descritto in questo articolo non ha un equivalente diretto in Design Patterns.

Ora è meglio seguire sempre questa pratica o solo qualche volta?

Se sì quando?

È mai eccessivo fare questo?

fonte

2012-03-16 cendrillon

È eccessivo quando è eccessivo. Solo tu puoi giudicarlo. In generale ti avvertirei di non seguire * qualche * saggezza ricevuta ciecamente. Di solito si scopre che tutte le qualifiche originali con cui è stata coperta la dichiarazione originale vengono dimenticate, rimane solo la regola, spesso nessuno sa davvero perché. – EJP

In questo caso siamo fortunati poiché il testo originale è conservato in tutta la sua gloria in Articolo 1 efficace di Java. Ma non sono sicuro che la mia interpretazione di ciò sia corretta. – cendrillon

Direi che è generalmente eccessivo, a meno che non si abbia un motivo specifico per voler nascondere il tipo effettivo che si sta creando, che è fondamentalmente quando si vuole usare un modello di fabbrica. Suggerisco che nella maggior parte dei casi non è così. Pensa a come sarebbe la vita, ad esempio se non riuscissi a costruire una stringa o una discussione. – EJP

In generale, i costruttori sono più semplici delle fabbriche, quindi questo è uno dei motivi principali per scegliere i costruttori su Factory. Usa Factory quando la situazione lo richiede, no "di default". Dovresti fare la cosa più semplice che risolve il tuo problema, e il più delle volte questo sarebbe costruttori.

fonte

2012-03-16 05:54:01 Oleksi

Mi piace il tuo ragionamento (il rasoio di Occam), tuttavia mi chiedo se rendere pubblico il costruttore potrebbe tornare a mordere più tardi. Una volta che è pubblico, non può più essere reso privato senza il rischio di rompere il codice esistente che ha fatto uso del costruttore. Ciò significa che l'adeguamento successivo di un metodo statico di fabbrica può essere doloroso. Suppongo anche che potrebbero esserci problemi di sicurezza dei thread. Non intendo mettere in dubbio la tua risposta, ma mi chiedo solo se c'è dell'altro oltre a questo? – cendrillon

Questa è una sorta di area chiamata di giudizio, ma un problema comune è che gli sviluppatori tendono a sovra-progettare il proprio codice. Anche se è vero che dovresti pensare al futuro, dovresti considerare _come è probabile_ richiedere un tale cambiamento. Quindi devi fare un giudizio. In generale, direi che più semplice è meglio. Questo è essenzialmente un argomento per YAGNI: http://en.wikipedia.org/wiki/You_ain't_gonna_need_it – Oleksi

Questo è un punto eccellente. Mi chiedo come bilanciare tra evitare l'overdesign da una parte e un buon incapsulamento, cioè minimizzare l'accessibilità di classi e membri? Cioè, il costruttore può sempre essere reso pubblico, ma una volta pubblico deve essere pubblico fino alla fine dei tempi. – cendrillon

Un approccio in fabbrica astrae la Creazione e configurazione di oggetti dal codice utilizzando l'oggetto.

Se tutto dipende dalla complessità implicata nella creazione e inizializzazione dell'oggetto. Se sono semplici, non è necessario utilizzare il modello di fabbrica.

Se è un po 'complesso (con molti passaggi in fase di inizializzazione prima di usarlo) e meglio andare con il modello di fabbrica.

fonte

2012-03-16 06:01:03 Santosh

Devo utilizzare sempre metodi di factory static invece di costruttori?

risposta

Problemi correlati