Tuttavia, nel suo discorso ha mostrato come "Extended Enums" sono stati al minor costo medio di un piccolo beneficio.
Ho iniziato a lavorare su "Extended Enums" (precedentemente "enum astratto"), in quanto il rilascio di OpenJDK e il lancio del defunto KSL (Kitchen Sink Language) nel 2006. Dalla quantità di colpi questo blog sta diventando il "enumerazioni estesa", so che questo tema è di grande preoccupazione per molti sviluppatori Java. Ho sviluppato una soluzione di lavoro, ma si fermò spingendo per esso per due motivi principali:Questa aggiunta alla lingua è una modifica al sistema di Java-type. Inoltre, non può essere una piccola modifica, ma è almeno un cambio medio.Guardando Tratti Scala o Fantom Mixin, ho avuto la sensazione che stava spingendo Java troppo, e forse nella direzione sbagliata.
Ho parlato con Joe Darcy a Devoxx09 su tutte le cose che ho scoperto l'attuazione del presente modifica al compilatore javac (e di altri cambiamenti necessari per le classi JDK). Era chiaro che il cambiamento è di medie dimensioni, ma non sono d'accordo che i benefici sono di piccole dimensioni.I benefici di "enumerazioni Extended" attuato oggi:Possibilità di dichiarazione enum per estendere una classe astratta realeQuesto è il vantaggio evidente, ed è un piccolo beneficio. Utilizzando la delega e / o in-allineato classi anonime non è troppo prolisso e offre gli stessi vantaggi. Ancora è più bello e più pulito per avere l'eredità normale OO.Possibilità di usare Generics nelle classi Enum Con "enumerazioni Extended" si può avere codice come questo:pubblico enum ActionQuery {{TUTTI getResults elenco pubblico () {...}}, {EDIT_ACTION getResults elenco pubblico () {...}}, {VIEW_ACTION getResults elenco pubblico () {...}}; pubblico getResults Lista astratto ();} trovo "enumerazioni Extended" molto utile per organizzare le query SQL e dei loro risultati, giocando con le proprietà e le loro tipologie, e così via.La caratteristica più importante e il motivo per cui ho sviluppato "enumerazioni Extended" è stato quello di avere la capacità di definire i parametri enum annotazione senza dover specificare il loro elenco di valori in anticipo. Si può già vedere il problema nella specifica JPA di oggi. C'è un enum FetchType che viene risolto nelle specifiche della pigrizia e ansiosi, ma Hibernate supporta anche subselect, che è approssimativamente tra pigra e impaziente. Per supportare subselect, è necessario utilizzare l'annotazione specifica Hibernate in combinazione con quella standard. Se il FetchType era un enum astratto, la specifica JPA non ha bisogno di imporre un elenco ben definito, ma potrebbe avere un DefaultFetchType proposto e consentono agli sviluppatori di attuazione e di applicazione JPA definire un enum nuovo con la loro lista desiderata di FetchType. Questo funziona già grande nel "astratto enum" Attuazione e mi fornisce con grandi benefici in molti altri settori: (come BindingType nella JSR-299 Contesto e Dependency Injection, enum dichiarazione Cache utilizzando la stringa di errore invece di prona per regione, Gruppo di JSR -303 utente convalida Bean utilizzando le enumerazioni definite invece delle interfacce vuote, e altro).
Dal mio punto di vista (e credo / spero non sono il solo), Joe Darcy colto il punto beneficio della enum estesa. E 'un grande vantaggio per il linguaggio Java.Questo era ed è la mia posizione per qualche tempo. "Votate per esteso Enums per il progetto Coin" Quello che mi ha spinto a ri-lancio, è ovviamente da Christof maggio soplets.org (che di impostazione del sito extended-enumerazioni: http://www.extended-enums.org/) , e il fatto che ho trovato un modo per apportare la modifica una "piccola". Fino ad ora, ero sicuro che per attuare correttamente questa una nuova bandiera era necessario il codice della classe di byte, e molti cambiamenti alla gestione di tipo Java sono stati necessari.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.