On numerous occasions I’ve seen Java code generated by other Java code as part of a standard build process. I’m not talking about “stub†or “boiler-plate†model code produced by tools such as rmic or hibernate, respectively, but logic code produced by a script. I’ve also seen this done in other languages, but it particularly bothers me when I see it done in an object-oriented language such as Java. Almost invariably it occurs for one of two reasons: an external dependency or structure prevents sane reuse practices, or a lack of modern object-oriented analysis and design skills. (The former case simply implies the latter on someone else’s part.)
Lame Dependencies
Some dependencies introduce more liabilities than benefits, yet are nevertheless necessary due to business or technological constraints. Libraries and frameworks that force you to extend specific classes (as opposed to interfaces) lessen your ability to create a flexible, adaptable application on top. When large amounts of boiler-plate code are necessary to satisfy a dependency, it might be reasonable to apply code generate techniques to avoid monotony; however, the generated code should at least adapt or delegate to a separate, reusable implementation.
Lame Developers (a.k.a. the people that write Lame Dependencies)
The pisser scenario that is often hard to differentiate from the former is a lack of OOA&D skills on behalf of the application designer. In particular, those accustomed to procedural thought may want to introduce “procedure generation” as a sort of clever closure mechanism which is more common in languages other than Java. This translates to large amounts of redundant, unnecessary code that could likely be avoided by applying modern design patterns and generics.
Conclusion
Classes are more than the place you put data and methods; together they implement a higher-level design which can be expressed in higher-level terms, isolated into components, and tested and maintained as such. If you have a system composed of a mesh of interwoven procedures with many statically bound components, mutual dependencies and generated logic, it may be more procedural than object-oriented.