Generalmente non dovrebbe esserci la necessità di ricostruire un'applicazione quando vengono introdotti nuovi dati. Se non è necessario definire e implementare una logica correlata al publisher ogni volta che viene introdotto un nuovo Publisher, enum è una scelta sbagliata.
Dove esattamente nella tua applicazione devi fare riferimento a un certo editore? Hai qualche logica legata all'editore nella tua applicazione? Come
if (article.getPublisher().equals(Publisher.NYPost) {
doSomethingNyPostRelated();
}
Hai qualche riferimento? Se non ne hai, non dovresti avere un set codificato di editori, come enum o altro.
I like the rigidity of using enum, but when might I get tripped-up if I treat the publisher as an enum instead of a String?
Che ne dici di una classe Publisher che non è un enum?
public class Publisher {
private final int id;
private final String name; // perhaps?
...
}
Ciò ti darebbe più rigidità di una stringa senza essere limitata a solo alcuni editori predefiniti codificati. In primo luogo, sarete in grado di controllare la creazione, la validità e l'uso degli editori. Secondo, avresti il tipo di sicurezza: non saresti in grado di passare o restituire una stringa casuale come un editore. In terzo luogo, puoi leggere un insieme predefinito di Publisher da un database o da un file di configurazione, qualunque sia il preferito:
public class PublisherRepository {
public List<Publisher> getAllPublishers() {
// read publishers from db or config file
}
}
Ovviamente potresti anche avere il tuo PublisherRepository che restituisce un elenco di editori con codice fisso all'inizio. Cambiare una soluzione hard codamente strutturata non sarebbe difficile come sostituire un enum.