代码生成器模式

重复的代码是程序员永远的敌人。坚持着这一思路，我一直非常反对在Java开发中使用代码生成工具，而坚信重复的代码是可以通过良好的结构给予消除的。

曾经代码生成器过度的使用也有一定的历史背景。比如说一些老的开发框架代码实现繁琐、反射和代理机制没有得到广泛的应用等等。慢慢的，岁月流转，有一部分的代码生成器消失不见了，但还有一些保留下来，根据存在既合理的前提，我也渐开始相信它们有自己存在的价值和意义。

有以下三种情况，使用代码生成器是合理的。

一、在代码生成器开发模式下有良好的技术积累，从保护现有技术价值和减少转换开发模式风险的角度来考虑而断续使用是可以接受的。一些代码生成器中的精品，可以从设计文件开始（如PD的设计），生成一个功能的雏形，虽然这些生成的代码也能通过公用的代码来实现，但为此而改变项目组的习惯开发方式并非上策，要知道，任何技术的更新都是要有代价的，也许你很愿意尝试但你的PM是否也这么想？

二、对代码执行速度有较高的要求时，代码生成器是一个好的选择。想实现通用的东西，必需要容忍它们之前的差异，而做的这一点if…else…、instanceof和Reflection这样的东西是少不了的。当这些代码以百万次的级别运行时，还是多考虑一些效率上的问题吧。通过Method.invoke()这样的方式调用对性能可是会有一个数量级上的损失，不像直接调用或通过接口——你几乎可以把它们排除到关于效率的思考之外。

三、具有类似并可转换的结构，但物理上确实分离——总感觉说不明白，这样的表达把我自己都快弄糊涂了。如果提起Hibernate Tools里可以根据数据库结构生成POJO类的功能，相信你会立刻明白，这类代码生成器更像是一种转换器，让生成的程序具有外部信息同样的结构。

在编写代码生成器时，还要注意以下方面：

首先，在生成代码的过程中是否有太多需要人为参与的地方？生成后的代码是否有可能需要进行改动？如果需要在生成过程中人为指定很多东西的话，这样的代码生成器是不成功的，不妨考虑更好的利用配置文件或是想一想代码生成的来源是否恰当。而生成后的代码如果人为进行了改动，那么当设计文件有所变化时，新生成的代码如何和以前的改动进行合并是一个让人头痛的问题。

其次，生成器产生的结果是代码而不是密码，它最终还是要给开发者进行阅读或调试。良好的代码风格和必要的注释一定要有，不能只因为是工具生成的就可以把要求降低到正常工作既可而无视实现的细节杂乱无章。

在项目中使用代码生成器是否能算是一种模式？我只是随意间用到了这个名称而无意讨论这个问题。至于打算进来一起研究“生成器模式”的读者更不妨对此一笑了之。