Generazione automatica del codice sorgente: buona idea o potenziale incubo? [duplicare]

Ho realizzato un progetto Java di medie dimensioni (circa 300 classi) con più Maven moduli con le mie classi di dominio generate automaticamente (ca 100 classi) da una DSL fatta con il superbo Eclipse Xtext progetto e vorrei rifarlo:)

Qui darò indicazioni su come io (fino ad oggi) sono riuscito a circondare con successo le pietre cumber menzionate:

Poiché il mio progetto è stato realizzato con maven ho usato il modo migliore per gestire il codice generato automaticamente, il che significa che anche il mio xtext dsl e il progetto generatore sono gestiti da maven e ad ogni build completo creo tutto il codice generato nuovo (come dovrebbe essere ). Vedere: costruzione di progetti xtext con maven tycho . Quindi nel mio progetto devo solo fare un "pacchetto Maven".

Ho diviso il mio codice generato e la mia mano digitato per via ereditaria (non mi piace il modo c # per estendere una classe in più file):

/* Generated code, will not be in revision control */
abstract class AbstractFoo {
    //getters and setters
    //collection accessors
    //helper methods like toString equals hashCode
}

/* Generated one time, will be in revision control */
class Foo extends AbstractFoo{
    //business logic if needed
}

Con un progetto generatore Xtext è possibile definire i file che devono essere creati una sola volta, quindi le mie lezioni concrete sono state create una sola volta e poi conservate nel mio repository Git. La classe concreta generata non è altro che una 2 fodera in modo da poter utilizzare la classe anche se non si aggiungono metodi.

Per i due modelli (astratti e concreti) ho creato due modelli di classi di test uno per la classe astratta e uno per il calcestruzzo, ma la classe di test concreta è di nuovo generata solo una volta e due di linea.

Nel mio modulo Maven in cui si trova il codice generato ho usato questo layout (quasi le convenzioni di esperti):

myproject/src/main/java -> concrete generated classes, one time
myproject/src/test/java -> generated tests, one time
myproject/target/generated-sources/mydsl -> abstract generated classes, always
myproject/target/generated-sources/mydsltests -> auto generated tests, always

Quindi, quando cambio il modello, il modello nel progetto del generatore Xtext cambierà nel mio controllo di revisione, poiché non includo le fonti (sempre) generate.

Quindi ti suggerisco di provare Eclipse Xtext, quando inizi con i progetti di esempio avremo qualcosa di prototipo in esecuzione in meno di un'ora.

Non mi piacerebbe questo approccio un po '. Troppo mistero per i miei gusti.

Preferirei aspetti o decoratori, perché devi effettivamente scriverli invece di generarli E chiarisci cosa stai facendo quando li intendi.

Da quello che ho visto, la generazione del codice sorgente funziona meglio se:

1. Non hai alcun motivo per modificare il codice della classe una volta generato o
2. Non avrai alcun motivo per rigenerare il codice di una classe dopo averlo modificato (approccio scaffolding) o
3. Stai lavorando in un linguaggio come C #, che ti permette di creare classi su più file. (Puoi avere un file con codice generato automaticamente e un altro con i tuoi contributi) o

In base alla tua domanda, immagino che nessuno di questi sia probabilmente vero. Anche se non ho seguito personalmente la generazione bytecode, ho notato che alcuni strumenti ben utilizzati come GWT hanno scelto questo approccio, quindi è probabilmente preferibile.

Tuttavia, chiederei a un collega di ascoltare ciò che stai cercando di realizzare e vedere se non c'è un modo migliore di usare più pratiche standard di Java.

Puoi avere il tuo processo di generazione generare il codice, scurirlo e includerlo nel classpath del tuo progetto dipendente. Ciò impedirà il problema con gli sviluppatori rogue che modificano la sorgente generata, non è necessario eseguire la versione del jar generato solo i metadati da cui è stato creato.

Questo è stato l'approccio che ho usato in passato con strumenti come XMLBeans e ha funzionato molto bene.

Il Eclipse Modeling Framework offre una straordinaria generazione di codice, ma è complicato da gestire. Apparentemente è in grado di consentire l'aggiunta di codice utente nel codice del modello senza ripristinare tali modifiche ogni volta che il modello viene rigenerato. Inoltre, l'editor dell'interfaccia utente di Mattise in Netbeans fa tutta la generazione per l'interfaccia utente e la mantiene aggiornata.

In realtà nei moduli c ++ gestiti hai entrambi i codici automatici e manuali mescolati insieme nel file .h. Il codice automatico viene aggiornato ogni volta che si apre il modulo in modalità Designer, si modifica qualcosa e si salva. Funziona altrettanto bene di aver generato il codice in un file separato.