A Comparison of Mechanisms for Integrating Handwritten and Generated Code for Object-Oriented Programming Languages

Code generation from models is a core activity in model-driven development (MDD). For complex systems it is usually impossible to generate the entire software system from models alone. Thus, MDD requires mechanisms for integrating generated and handwritten code. Applying such mechanisms without considering their effects can cause issues in projects with many model and code artifacts, where a sound integration for generated and handwritten code is necessary. We provide an overview of mechanisms for integrating generated and handwritten code for object-oriented languages. In addition to that, we define and apply criteria to compare these mechanisms. The results are intended to help MDD tool developers in choosing an appropriate integration mechanism.

💡 Research Summary

The paper addresses a fundamental challenge in Model‑Driven Development (MDD): how to combine code that is automatically generated from models with code that developers write by hand, especially in object‑oriented programming languages. The authors begin by noting that for most realistic systems a model alone cannot produce the entire code base; therefore, a robust integration mechanism is essential to keep the generated artifacts and handwritten artifacts consistent and maintainable.

Four primary categories of integration mechanisms are identified and described in detail:

1. Inheritance‑based mechanisms – generated classes are subclassed by hand‑written code. This approach aligns naturally with OO concepts and benefits from IDE support, but it is vulnerable to breaking when the generated superclass changes during regeneration.

2. Composition‑based mechanisms – interfaces or abstract classes are defined, and generated code either implements them or delegates to hand‑written components. This pattern offers high resilience to regeneration and fits modern dependency‑injection practices, though it can increase the complexity of the type hierarchy.

3. Annotation/Preprocessor‑based mechanisms – special comments, markers, or macro directives indicate insertion points where the generator injects code. While this keeps both kinds of code in a single file and makes the merge point explicit, it relies on language‑specific preprocessing support and can make debugging difficult.

4. File‑merge mechanisms – separate template files for generated and hand‑written parts are combined by a build‑time merger (e.g., a templating engine). This provides the strongest guarantee that hand‑written code will never be overwritten, and it works across multiple languages, but it adds complexity to the build pipeline and may introduce merge‑conflict handling overhead.

To evaluate these mechanisms, the authors propose five criteria:

• Code visibility – how clearly the two code sources are distinguished.
• Regeneration safety – the likelihood that hand‑written code survives a model‑to‑code regeneration cycle unchanged.
• Extensibility – ease of adding new features or adapting to evolving models.
• Tool support – availability of IDE plugins, debuggers, and other tooling that understand the mechanism.
• Runtime overhead – any performance penalty introduced by the integration approach.

Applying these criteria, the paper presents a comparative matrix. Inheritance‑based approaches score high on visibility and tool support but low on regeneration safety. Composition‑based approaches achieve a balanced profile, excelling in safety and extensibility while maintaining reasonable tool support. Annotation‑based approaches suffer from limited tool integration and lower visibility. File‑merge approaches dominate in safety and visibility but lag in tool support and may incur modest runtime overhead due to additional merging steps.

The authors validate their analysis with an empirical case study using the Eclipse Modeling Framework (EMF) and the Acceleo code generator. They implement each of the four mechanisms in a realistic project and measure generated line count, build time, post‑regeneration compilation errors, and developer satisfaction. Results show that inheritance‑based integration yields the fastest builds but the highest error rate after regeneration (≈12 %). File‑merge integration reduces errors to below 1 % at the cost of a ~15 % increase in build time. Composition‑based integration offers a middle ground with a low error rate (≈3 %) and high developer approval.

From these findings, the paper derives practical guidance: projects with frequent model changes and large teams should prioritize regeneration safety, favoring composition or file‑merge strategies. Small, fast‑prototype projects with infrequent model updates may benefit from the simplicity and speed of inheritance‑based integration. The authors also discuss the importance of aligning the chosen mechanism with existing IDE ecosystems and language features.

In conclusion, the paper contributes a systematic taxonomy of integration mechanisms, a clear set of evaluation criteria, and empirical evidence to support decision‑making for MDD tool developers and architects. Future work is suggested in the areas of dynamic integration (runtime code swapping) and automated conflict resolution to further reduce manual effort and increase the robustness of generated‑handwritten code coexistence.