Generación automática de código fuente: ¿buena idea o potencial pesadilla? [duplicar]

He realizado un proyecto Java de tamaño medio (aproximadamente 300 clases) con varios módulos de Maven con mis clases de dominio generadas automáticamente (ca .100 clases) de un DSL hecho con el excelente proyecto Eclipse Xtext y lo haría de nuevo :)

Aquí le daré sugerencias sobre cómo (hasta hoy) he logrado superar las piedras cegadoras mencionadas:

Dado que mi proyecto se compiló con maven, utilicé la forma de maven para manejar el código generado automáticamente, eso significa que incluso mi proyecto xtext dsl y generator es manejado por maven y en cada compilación completa creo todo el código generado nuevo (como debería ser) ). Ver: construyendo proyectos xtext con maven tycho . Así que en mi proyecto solo tengo que hacer un "paquete de Maven".

Dividí mi código generado y escribí mi mano por herencia (no me gusta la forma c # de abarcar una clase en varios archivos):

/* 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 proyecto de generador de Xtext es posible definir archivos que solo deben crearse una vez, por lo que mis clases concretas las he creado una sola vez y luego las guardé en mi repositorio de Git. La clase concreta generada no es más que un forro de 2 líneas, por lo que puedes usarla incluso si no le agregas ningún método.

Para las dos plantillas (abstracta y concreta), he creado dos plantillas de clase de prueba, una para la clase abstracta y otra para la concreta, pero la clase de prueba concreta solo se genera una vez y dos liners.

En mi módulo de Maven, donde se encuentra el código generado, he usado este diseño (casi las convenciones de Maven):

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

Entonces, cuando cambio la plantilla, solo la plantilla en el proyecto del generador de Xtext cambiará en mi control de revisión, ya que no incluyo las fuentes (siempre) generadas.

Por lo tanto, le sugiero que pruebe Eclipse Xtext. Cuando comience con los proyectos de ejemplo, tendrá algo en funcionamiento en un prototipo en menos de una hora.

No me gustaría este enfoque un poco. Demasiado misterio para mi gusto.

Prefiero los aspectos o decoradores, porque tienes que escribirlos en lugar de generarlos Y dejar en claro lo que estás haciendo cuando los tejes.

Por lo que he visto, la generación de código fuente funciona mejor si:

1. No tiene ningún motivo para modificar el código de la clase una vez que se haya generado, o
2. No tendrá ningún motivo para volver a generar el código de una clase una vez que lo haya modificado (enfoque de andamiaje), o
3. Estás trabajando en un lenguaje como C #, que te permite hacer que las clases abarquen varios archivos. (Puede tener un archivo con código generado automáticamente y otro con sus contribuciones), o

Según su pregunta, supongo que ninguno de estos es probablemente cierto. Si bien no he hecho personalmente la generación de código de bytes, he notado que algunas herramientas bien utilizadas como GWT han elegido ese enfoque, por lo que probablemente sea preferible.

Sin embargo, le pido a un colega que escuche lo que está tratando de lograr y vea si no hay una mejor manera de usar prácticas Java estándar.

Puede hacer que su proceso de compilación genere el código, lo elimine y lo incluya en el classpath de su proyecto dependiente. Esto evitará que el problema con los desarrolladores deshonestos cambien la fuente generada, no es necesario que la versión del contenedor generado solo los metadatos desde los que se generó.

Este fue el enfoque que he usado en el pasado con herramientas como XMLBeans y funcionó bastante bien.

El Eclipse Modeling Framework hace una generación de código realmente excelente, pero es complicado de manejar. Aparentemente, es posible permitir adiciones de código de usuario en el código del modelo sin revertir esos cambios cada vez que se regenera el modelo. Además, el editor Mattise UI en Netbeans hace toda la generación para la interfaz de usuario y lo mantiene actualizado.

En realidad, en los formularios de c ++ administrados, los códigos automático y manual se mezclan en el archivo. El código automático se actualiza cada vez que abre un formulario en modo diseñador, modifica algo y guarda. Funciona igual de bien que genera código en un archivo separado.