Abbiamo mai bisogno di preferire i costruttori rispetto ai metodi statici di fabbrica? Se sì, quando?

Question

Ho letto Java efficace di Joshua Bloch e finora è all'altezza della sua reputazione. Il primo elemento costituisce un caso convincente per i metodi di produzione statica su . Tanto che ho iniziato a mettere in discussione la validità dei buoni vecchi costruttori :).

i vantaggi/svantaggi del libro sono riassunte di seguito:

Vantaggi:

1. Hanno nomi!
2. Abbiamo totale controllo esempio (Singletons, prestazioni, ecc)
3. Essi possono restituire un sottotipo/interfaccia
4. compilatore può fornire inferenza

Svantaggi:

1. Le classi private non possono essere sottoclasse
2. Non si distinguono nella documentazione come costruttore s do

Il primo svantaggio può effettivamente essere una buona cosa (come menzionato nel libro). Il secondo, penso sia solo uno svantaggio minore e può essere risolto facilmente con le prossime versioni java (annotazioni per javadoc ecc.)

Sembra che alla fine i metodi di fabbrica abbiano quasi tutti i vantaggi dei costruttori, molti molti altri vantaggi e nessun vero svantaggio!

Quindi, la mia domanda è sostanzialmente in tre parti:

1. E 'buona prassi utilizzare sempre metodi di fabbrica statici di default sopra i costruttori?
2. È mai giustificato utilizzare i costruttori?
3. Perché i linguaggi orientati agli oggetti non forniscono supporto a livello di lingua per le fabbriche?

Nota: Ci sono due domande simili: When to use a Constructor and when to use getInstance() method (static factory methods)? e Creation of Objects: Constructors or Static Factory Methods. Tuttavia, le risposte o forniscono semplicemente l'elenco sopra riportato o reiterano la logica dietro i metodi statici di fabbrica di cui sono già a conoscenza.

Answer 1

Le fabbriche statiche devono ancora chiamare un costruttore alla fine. È possibile spostare la maggior parte delle funzionalità nel factory statico, ma non è possibile evitare di utilizzare un costruttore.

D'altra parte per casi semplici, si può avere solo un costruttore senza avere una fabbrica statica.

I costruttori sono l'unico modo per impostare i campi finali, che IMHO sono preferibili ai campi non finali.

È possibile utilizzare i costruttori possono nelle sottoclassi. Non è possibile utilizzare le fabbriche statiche per una sottoclasse.

Se si dispone di una buona infrastruttura di dipendenza per le dipendenze di un componente, è possibile che le fabbriche statiche non aggiungano molto.

Answer 2

Mi piace il commento di una delle domande simili che hai evidenziato:

(Su come decidere se è necessario favorire un metodo factory per un costruttore),

"è necessario decidere che cosa' Se non vuoi che le persone chiamino il tuo costruttore (stai creando un singleton o una factory), o non ti dispiace (come in NumberFormat sopra, dove stanno inizializzando alcuni oggetti per comodità del chiamante) "

Per me, questo significa che è giustificato a utilizzare un costruttore, dove non è richiesto il metodo factory. Senza alcuna necessità di una fabbrica, rende il codice più difficile da seguire ("quale sottoclasse esatta viene restituita qui?")

Answer 3

Sono molto d'accordo con Josh Bloch qui, e rende il caso migliore di quanto avrei potuto, ma qui ci sono alcuni luoghi in cui le fabbriche statiche non sono appropriate:

• Quando l'iniezione di dipendenza è più sensibile; I sistemi DI (certamente Guice) tendono a iniettare le cose attraverso i loro costruttori. In particolare, DI è appropriato quando ci si aspetta che i parametri del costruttore possano cambiare in futuro.
• Quando si intende specificamente per le persone scrivere sottoclassi e si sta fornendo uno scheletro da implementare.

Answer 4

I costruttori sono noiosi, sai esattamente dove cercarli, conosci il loro scopo, sono in qualche modo prevedibili. Sono lì per costruire l'oggetto stesso, non per fare lavori simili a Dio. Se stai facendo troppe cose che non hanno molto a che fare con la costruzione dell'oggetto sai che stai facendo qualcosa di sbagliato. E non è possibile "curarlo" semplicemente rinominando il metodo. Quindi tendono ad essere più focalizzati, "migliori" nella qualità del codice quando non si hanno sviluppatori top-of-the-line. (Quando hai questi ultimi i punti che ho menzionato non hanno importanza.)

Noioso. Facciamo qualcosa di più divertente e intellettuale impegnativo ...

Giusto per la cronaca: non trascuro i punti menzionati nella domanda e altre risposte, volevo solo aggiungere questo punto aggiuntivo.