Potrebbe EnumMap essere considerata una ragionevole alternativa ai fagioli Java?

Question

curioso se qualcuno ha pensato di utilizzare EnumMap al posto di fagioli Java, in particolare "oggetti di valore" (con nessun comportamento)? A me sembra che un vantaggio sarebbe che il nome di una "proprietà" sarebbe accessibile direttamente dalla Enum supporto, senza bisogno di riflessione, e quindi mi piacerebbe pensare che sarebbe stato più veloce.

Answer 1

possono essere un po 'più veloce quindi utilizzando riflessione (non ho misurarlo, non ha trovato nessun metriche in Google o); tuttavia ci sono grandi svantaggi di questo approccio:

1. Stai perdendo sicurezza tipo. Invece di int getAge() e String getName() tutto è Object get(MyEnum.FIELD_NAME). Che sarà prevedono un certo codice brutto e run-time errori proprio lì.

2. Tutte le sottigliezze JavaBean che abbiamo imparato ad amare e godere (per esempio, le annotazioni a livello di proprietà) se ne sono andati.

3. Dal momento che si può avere nessun comportamento a tutti, l'applicabilità di questo approccio sembra piuttosto limitata.

La linea di fondo è - se si ha realmente veramente bisogno di quella presunta spinta :-) in termini di prestazioni (che si dovrà misurare per dimostrare che esiste) questa può essere una soluzione valida in circostanze molto specifiche. Si tratta di una valida alternativa al JavaBeans in generale? Certamente no.

Answer 2

Un chicco è destinata ad essere mutevoli, quindi i metodi setter. EnumMap è paragonabile in termini di velocità di utilizzare un HashMap con numeri interi come la chiave, ma sono le chiavi sono immutabili. Fagioli e EnumMaps servono due scopi diversi. Se tutti i tasti sono noti in fase di progettazione e sono garantiti per non cambiare mai, quindi utilizzando un EnumMap andrà bene.
Aggiornamento di un fagiolo è molto più semplice cambiare il sostegno Enum del EnumMap con molto meno possibilità di creare errori a valle nel codice.

Answer 3

ho scritto una classe Record che mappa le chiavi ai valori e lavora delegando ad un EnumMap completamente sincronizzato. L'idea è che un record può ottenere nuovi campi in fase di esecuzione, mentre l'Bean non può. La mia conclusione è che con questa flessibilità ha un calo di prestazioni. Ecco una corsa a confronto la classe Record per un Bean completamente sincronizzato. Per 10 milioni di operazioni:

Record  set(Thing, a)  458 ms
Bean    setThing(a)    278 ms
Record  get(Thing)     398 ms
Bean    getThing       248 ms

Quindi, c'è qualcosa da guadagnare a conoscere i vostri oggetti di dati e la scrittura di una classe che li modelli staticamente. Se si desidera avere nuovi campi imbottiti ai vostri dati in fase di esecuzione, vi costerà.

Answer 4

Non capisco come è possibile rimuovere 'classe profileration' con EnumMaps. Se non avete un enum generico con proprietà di 20 e rotti di riutilizzare per ogni 'fagiolo', si sta ancora inventando un enum da utilizzare per ogni mappa enum, per es.

public enum PersonDTOEnum {
     A, S, L;
}

a differenza di

class Person {

    int a;
    int s;
    String l;

    // getters + setters elided
}

Per non parlare che tutto è una stringa ora.

Answer 5

Non avevo specificato in precedenza questo, ma sto lavorando con un ResultSet. Perciò io voglio fornire questa risposta per ragioni di completezza.

Commons / di BeanUtil 'RowSetDynaClass' potrebbe essere la via di mezzo tra il boilerplate eccessiva associata con i fagioli di cemento, e le limitazioni di EnumMap