Qual è il vantaggio per Collections.singleton() per restituire un set anziché una raccolta?

Question

Collections.singleton() method restituisce un Set con tale argomento singolo anziché Collection.

Perché è così? Da quello che posso vedere, a parte il Set come sottotipo di Collection, non vedo alcun vantaggio ... È solo perché Set si estende comunque allo Collection quindi non c'è motivo di non farlo?

E sì, c'è anche Collections.singletonList() ma questo è un altro discorso dato che è possibile accedere agli elementi casuali da una List con .get() ...

Answer 1

io non sono sicuro che ci sia un "beneficio" o "vantaggio" di per sé ? È solo il metodo che restituisce un singleton Set, e sembra essere l'implementazione predefinita quando si desidera un singleton Collection, dal momento che un singleton Collection sembra essere un insieme matematico.

Answer 2

Non tutti gli elenchi sono ad accesso casuale, basta prendere un LinkedList (accesso casuale nell'API, non nell'implementazione) come contro-esempio. Per come sono d'accordo con Louis Wasserman, uno Set ha semplicemente un senso perché è più vicino alla definizione matematica, è semplicemente naturale.

Answer 3

Mi sono chiesto la stessa cosa e ho trovato la tua domanda nella mia ricerca. Ecco la mia conclusione:

Il ritorno a Set mantiene pulita l'API di raccolta.

Qui ci sono i metodi per ottenere una collezione Singleton:

• public static <T> Set<T> singleton(T o)
• public static <T> List<T> singletonList(T o)
• public static <K,V> Map<K,V> singletonMap(K key, V value)

Che cosa succede se i progettisti API hanno deciso di avere un metodo di singletonSet metodo e singleton ? Sarebbe simile a questa:

• public static <T> Collection<T> singleton(T o)
• public static <T> Set<T> singletonSet(T o)
• public static <T> List<T> singletonList(T o)
• public static <K,V> Map<K,V> singletonMap(K key, V value)

è il metodo singleton davvero necessario? Pensiamo al motivo per cui avremmo bisogno di alcuni di questi metodi.

Pensa a quando chiameresti singletonList? Probabilmente hai un'API che richiede List anziché Collection o Set. Userò questo cattivo esempio:

public void needsList(List<?> list); 

È possibile passare solo un List. needsList ha bisogno di dati indicizzati e non richiede arbitrariamente uno List anziché uno Collection.

Tuttavia, si potrebbe anche passare un List a un metodo che ha richiesto alcun Collection:

public void needsAnyCollection(Collection<?> collection); 

Ma se questo è il caso, allora perché usare un List? A ha un'API più complicata e prevede la memorizzazione di indici. Hai davvero bisogno degli indici? Set non è sufficiente? Io sostengo che si dovrebbe usare un Set, perché needsAnyCollection non si preoccupa per l'ordine.

Questo è dove singletonSet brilla davvero. Sai che se la collezione è di taglia 1 (singleton), allora i dati devono essere unici. Le raccolte di dimensione 1 sono casualmente un Set.

Non è necessario un metodo che restituisce un singleton di tipo Collection, perché è accidentalmente un Set.

Answer 4

Immutabile

Il beneficio si trova nel primo aggettivo letto in that JavaDoc documentation: immutabili.

Ci sono momenti in cui si sta lavorando con codice che richiede uno Set (o , ecc.). Nel tuo stesso contesto potresti avere un rigoroso bisogno di un solo oggetto. Per raggiungere il tuo obiettivo di applicare la regola del singolo elemento solo mentre devi presentare quell'elemento in un set, usa un'implementazione Set che ti impedisce di aggiungere più di un elemento.

"Immutabile" su Collections::singleton significa che, una volta creato, l'oggetto Set risultante è garantito per avere uno e un solo oggetto. Non zero e non più di uno. Non è possibile aggiungere altro. L'unico oggetto non può essere rimosso.

Ad esempio, immagina che il tuo codice funzioni con un oggetto Employee che rappresenta il CEO (Chief Executive Officer) della tua azienda. Il tuo codice si riferisce esplicitamente solo al CEO, quindi sai che può esserci solo uno di questi oggetti Employee alla volta, sempre esattamente un amministratore delegato. Tuttavia, si desidera sfruttare un codice esistente che crea un report per una raccolta specificata di oggetti Employee. Usando Collection.singleton si garantisce che il proprio codice non abbia erroneamente un altro dipendente, pur essendo ancora in grado di passare un Set.

Set<Employee> ceo = Collections.singleton(new Employee("Tim Cook")) ; // Always exactly one item in this context, only one CEO is possible. 

ceo.add(…) ;  // Fails, as the collection is immutable. 
ceo.clear() ;  // Fails, as the collection is immutable. 
ceo.remove(…) ; // Fails, as the collection is immutable. 

someReport.processEmployees(ceo) ; 

Java 9: ​​Set.of & List.of

Java 9 e versioni successive offre nuovi metodi di interfaccia Set.of e List.of Th stesso effetto, una collezione immutabile di un singolo elemento.

Set<Pet> pet = Set.of(someDog) ; 

Ma fratello of metodi sono sovraccarichi di accettare qualsiasi numero di elementi per essere nella collezione immutabile, non solo un elemento.

Set<Pet> pets = Set.of(someDog , someOtherDog , someCat) ;