Perché gli oggetti LocalDate, LocalTime e Stream utilizzano un metodo factory of() invece di un costruttore?

Question

Perché gli oggetti LocalDate, LocalTime, Stream, ecc. Utilizzano un metodo di fabbrica of() invece di un costruttore?

Ho trovato una spiegazione del motivo per cui devono essere utilizzati metodi di fabbrica anziché newhere. Questa risposta dà una serie di motivi, ma l'unica cosa che è rilevante per Java Data/Ora API è la seguente:

a differenza di costruttori, essi non sono tenuti a creare un nuovo oggetto ogni volta che vengono invocati

Come LocalDate e LocalTime sono immutabili, probabilmente ha senso utilizzare una fabbrica e riutilizzare gli oggetti esistenti invece di creare un nuovo oggetto ogni volta.

E 'il motivo per cui vengono creati oggetti come LocalDate e LocalTime con un metodo factory (vale a dire, LocalDate.of())? Ci sono altri motivi?

Inoltre, gli oggetti Stream sono modificabili. Perché un metodo factory (Stream.of()) viene utilizzato per creare un Stream?

Answer 1

Perché un metodo factory (Stream.of()) viene utilizzato per creare un flusso?

Utilizzare un metodo di fabbrica significa che non è necessario conoscere la classe esatta utilizzata. Questo è un buon esempio dato che Stream è un'interfaccia e non è possibile creare un'istanza di un'interfaccia.

Dalla sorgente per Stream.of

/** 
* Returns a sequential {@code Stream} containing a single element. 
* 
* @param t the single element 
* @param <T> the type of stream elements 
* @return a singleton sequential stream 
*/ 
public static<T> Stream<T> of(T t) { 
    return StreamSupport.stream(new Streams.StreamBuilderImpl<>(t), false); 
} 

/** 
* Returns a sequential ordered stream whose elements are the specified values. 
* 
* @param <T> the type of stream elements 
* @param values the elements of the new stream 
* @return the new stream 
*/ 
@SafeVarargs 
@SuppressWarnings("varargs") // Creating a stream from an array is safe 
public static<T> Stream<T> of(T... values) { 
    return Arrays.stream(values); 
} 

Nota: questi metodi chiamare altri metodi di fabbrica.

Si può vedere che si ottengono diverse costruzioni a seconda di come viene chiamato. Non hai bisogno di sapere questo o quello che è stato creato dalla classe definitiva che è ReferencePipeline.Head

Answer 2

+1 alla risposta di Peter.

Un altro motivo per utilizzare i metodi di fabbrica è che si comportano come "costruttori nominati".

Ad esempio, LocalDate ha 6 metodi factory statici (almeno, non posso essere esaustivo qui):

• of(int year, int/Month month, int dayOfMonth) (due overload)
• ofEpochDay(long epochDay)
• ofYearDay(int year, int dayOfYear)
• parse(CharSequence text)
• parse(CharSequence text, DateTimeFormatter formatter)

Penso che sia molto più chiaro capire i significati dei vari parametri avendo questi come metodi con nomi separati, piuttosto che un gruppo di costruttori con tipi di parametri molto simili; puoi praticamente indovinare quali dovrebbero essere i parametri per i metodi factory, mentre potresti dover leggere il Javadoc (shock horror) se fossero costruttori "senza nome".

Certo, of è il meno chiara di questi nomi - uno potrebbe desiderare ofYearMonthDayOfMonth - tuttavia, ho il sospetto che questo è il metodo factory più comunemente usata, ed è semplicemente troppo ingombra di digitare quel nome lungo tutto il tempo.

---

Nel caso in cui non l'ho letto, punto 1 del Effective Java 2nd Edition è tutto perché e quando a preferire metodi di fabbrica statici sopra costruttori. Il vantaggio del "costruttore nominato" che cito qui è in realtà il primo vantaggio di Bloch.