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

13

In risposta a sulla mia domanda riguardante la generazione del codice sorgente Java , ho ricevuto questa risposta mi avverte di potenziali problemi di manutenzione:

  1. mixing auto-generated code always pose a risk of someone modifying it in future to just to tweak a small behavior. It's just the matter of next build, when this changes will be lost.
  2. you will have to solely rely on the comments on top of auto-generated source to prevent developers from doing so.
  3. version-controlling - Lets say you update the template of someMethod(), now all of your source file's version will be updated, even if the source updates is auto-generated. you will see redundant history.

La sua alternativa proposta è migliorare le classi in fase di runtime utilizzando la generazione bytecode.

Il mio pensiero era che l'iniezione di codice generato in file di codice sorgente esistenti avrebbe migliorato la manutenibilità, perché rende evidente ciò che sta accadendo invece di eseguire alcune operazioni dietro le quinte.

Dovrei:

  1. crea uno strumento per aggiungere codice generato al codice sorgente esistente; o

  2. estendere le classi utilizzando la generazione bytecode in fase di runtime?

Qual è stata la tua esperienza con entrambi questi approcci?

    
posta Tony the Pony 21.04.2011 - 17:14
fonte

6 risposte

15

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.

    
risposta data 22.04.2011 - 04:19
fonte
7

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.

    
risposta data 21.04.2011 - 17:21
fonte
5

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.

    
risposta data 21.04.2011 - 17:24
fonte
4

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.

    
risposta data 21.04.2011 - 17:32
fonte
2

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.

    
risposta data 21.04.2011 - 17:23
fonte
1

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.

    
risposta data 23.04.2011 - 08:26
fonte

Leggi altre domande sui tag