Esistono due modi per utilizzare CopyOnWriteArraySet:
// A
Set<Object> set = new CopyOnWriteArraySet<>();
e
// B
CopyOnWriteArraySet<Object> set = new CopyOnWriteArraySet<>();
Con set "normali" come HashSet e TreeSet, il caso A è preferito, perché consente di cambiare facilmente l'implementazione Set .
Tuttavia, in questo caso viene presa una scelta consapevole per un'implementazione Set specifica per thread-safe. Dovrei usare il caso B per significare questo intento?
È possibile dichiarare deliberatamente un tipo più specifico per documentare la politica di threading. Tuttavia, una politica di threading funzionante richiede molto più dei tipi scelti con giudizio, quindi non aggiunge molto valore.
Nel tuo esempio, stai invocando il costruttore della classe concreta nella stessa linea, quindi la scelta sarebbe stata ovvia anche in ogni caso. Sarebbe più utile utilizzare i tipi per comunicare se il set è stato restituito a un utente esterno, ad es. tramite un'interfaccia o un metodo di ritorno.
Dipende tutto da chi vuoi segnalare questo intento.
Specifiche della tua implementazione non dovrebbero essere trapelate ai tuoi clienti. Come @Killian menziona, se questo fatto è significativo per i client che utilizzano la tua funzionalità, puoi documentare il tuo intento in un'interfaccia che nasconde la tua effettiva implementazione.
Se vuoi segnalare questo a persone che possono effettivamente modificare il codice, di nuovo, questo può essere facilmente documentato con il metodo, il livello di interfaccia che nasconde l'implementazione.
Suggerirei di attenersi al primo caso per la flessibilità (dato che è possibile passare a un'altra implementazione simile) e indicare chiaramente le intenzioni nella documentazione. Ovviamente, avere i test unitari giusti impedirà alle persone di aggiungere set "sbagliati".
Leggi altre domande sui tag design java multithreading