A well-known, and in our opinion, false assertion about code generation is, that it is a sign of a bad design to need something like this at all. There are, of course, cases where this is true. Most of the time, though, you need to be concerned about the division of your solutions into “generic” and “generative”, and there is most definitely no single best strategy here.

Consider, for example, mapping objects, their relations, and their associations, to code. One way to address this is to statically type your classes according to your model - have a get and set method for your attributes, a Java class for each model class, use e.g. java.util.Vector to contain associated objects. If you want to do this, and have a model that exceeds trivial complexity, a generative approach - i.e., using iQgen - is a perfect match.

On the other hand, you could also define a class called ApplicationObject with a java.util.HashMap to hold the attributes, keyed by their name. You could then change your business model (to a certain degree) without touching your code, too.

Which of these solutions is better? Clearly, there is no simple answer to this question, since it depends very much on your specific requirements. Quite often, a generative approach will improve performance and make code easier to read, since it is a lot more explicit than the generic solution. Generic solutions work at compile time, though, so sometimes they might be too inflexible for a given problem. Generating code can also significantly enhance your code base, which might hurt both performance at run time and turn-around cycles at development time. Quite often, a thin veneer that is generated at compile time and wraps the generic object structure is a possible solution.

In summary, there can be no clear, universal preference to either solution. Each project requires careful consideration of the requirements at hand, and to find the right balance requires a skilled software architect.