¿Cambiar código generado o usar herencia?

Question

Trabajo en un proyecto EMF. Una de las decisiones de diseño fue no tocar el código generado y no verificarlo. En cambio, cada vez que se necesita cambiar algo, se crea una subclase que contiene los cambios. El marco es lo suficientemente flexible como para hacer frente a esto. Sin embargo, experimento un poco de trabajo por encima.

La decisión de diseño se tomó sobre la base de las malas experiencias con otros marcos de generación de código. Se generaron problemas de regeneración.

Siendo nuevo en el proyecto, me gustaría desafiar esa decisión de diseño pero me gustaría escuchar primero la opinión general. Sé que el equipo del proyecto EMF recomienda los cambios dentro del código. Pero, ¿cuáles son tus experiencias? ¿Qué tan bien maneja EMF los cambios de código manual en el código generado? ¿Alguna vez llegaste a un punto en el que perdiste el código escrito manualmente? ¿Alguna vez el código entró en un estado no sostenible?

Answer 1

¿Pero cuáles son sus experiencias?

Implementé dos proyectos separados, los cuales involucraron modelos con 50 o más clases de modelos, y en ambos casos los modelos evolucionaron a lo largo de la vida del proyecto; es decir, lotes de cambios de modelo. En ambos casos, modifiqué el código generado para implementar atributos calculados, validación y personalizar los editores de varias maneras.

¿Qué tan bien EMF manejar cambios manual de código en el código generado?

Funciona bien. Ocasionalmente, el generador produce código que no se compila debido a algún cambio en el modelo, pero las correcciones suelen ser simples; p.ej. eliminación de clases/interfaces Java, importaciones muertas, etc.

¿Alguna vez llegó a un punto en el que perdió el código escrito manualmente?

Solo muy ocasionalmente. De vez en cuando, te olvidas de eliminar el comentario del marcador "generado" y tu método queda destruido cuando vuelves a generar el modelo.

(supongo que si se trataba de una de las principales preocupaciones que podría modificar el generador de campos electromagnéticos para siempre copia de seguridad del árbol de origen antes de la fusión de cambios.)

supongo que lo más irritante era que el código generado tenía que ser formateado. Desafortunadamente, el formateador de código Eclipse es bastante complicado, pero si se formatea manualmente, , los cambios de formato serán eliminados la próxima vez que se regenere. Pero eso es irritante ... no es algo que vale la pena saltar por los aros para evitarlo.

¿Alguna vez el código entró en un estado no sostenible?

Nope. Jamas.

---

La lectura de la respuesta de consta_a me recuerda que siempre controlé las clases EMF generadas en el control de versiones. Esa es la mejor manera de evitar perder ediciones manuales a largo plazo.

Answer 2

Confirmo la respuesta de Stephen C: en nuestro caso manejamos alrededor de 120 clases en nuestro modelo, lo que significa 120 interfaces + 120 clases de implementación + innumerables clases de edición y regeneración va bastante bien (si solo pudiéramos formatear fácilmente las clases generadas como queremos (^ _ ^))

Consejo: Si teme perder algún código hecho a mano, lo mejor es mantener el código en un repositorio. Cada vez que haces un cambio, puedes compararlo fácilmente con la versión anterior y ver qué ha cambiado.