四、 注释——有所为，有所不为
注释作为元数据的保存或是持有是很实用的。例如，在构建一个实体类或是控制器时变得很方便。同时，在两个不同类之间进行关联时也很有用。
但是，如果把注释作为配置目的来使用，则有违它最初的设计初衷。因为配置文件或信息是经常需要修改的，例如数据库的映射文件等，在这方面使用注释，显然有滥用或过分使用的成分。因此，在这方面，Java EE5.0及Hibernae走得有点偏了，这常常使得注释在元数据与配置文件之间混用。
但是，这并不能说注释是有问题的，只能说是使用者误用问题造成的。注释比较适合用于元数据的定义或保存。但并不适用于应用运行的配置信息。
此外，注释另外一个很成功的应用可能就是在JUnit4 API里的应用。如：
增加一个@Test注释，而不需要像以前那样写成testXxx()；
增加一个@Test注释，就可以替代以前的try/catch出错处理了；
增加一个@Before@After注释，可以替换以前的setUp()等方法；
增加一个@RunWith(Parameterized.class)及一个方法@Parameters public static Collection<Object[]> parameters()，被测试类的构造参数都保存在Object[]里。这样就进行参数化的测试了，而无须像从前那样public static Test suite()。
据笔者所知，JUnit框架中注释的使用，的确使它变成更加的灵活，代码更加的紧凑。
其实，注释只是我们普通开发人员手里的一个工具，它也许是一个新玩意，带有几分的新鲜，但也有几分的讨厌，其实也是一把双刃剑。笔者记得当初学习设计模式的时候，就想把所有的这些模式赶快应用到开发当中，不管适用不适用。只有当这种新鲜感过后，才能正常与正确的使用这些新特性。
五、 小结
那注释到底用还是不用呢？笔者认为，把注释应用到有意义的地方，而不是一味的滥用即可。例如，在那些没有注释就不能运行的地方肯定需要就注释。再如，改变注释将可能导致运行时类的行为，那可以考虑使用注释。
Java EE5.0使用注释这样新语法，替代XML，当然，修改元注释还是需要重新编译的，这和修改源码没有两样，但是如果没有单元测试这一人工工程管理跟上，程序上线正式运行，因为粗心等各种琐碎问题全部爆发，更是可怕。
另外，笔者认为，ROR中的约定优于配置（Convention Over Configuration ），这种做法Java的框架可以借鉴一下，在前期把问题都解决，这总比到了维护实施后期左找右改XML要强吧，牺牲了灵活性得到的却是可靠和稳定。使用ROR这样的解释语言，对于注释的修改是不需要编译，当然约定优于配置不是ROR首先提出来，默认简单，容易上手，需要细节还是可以使用XML配置。总之，约定优于配置是基于XML基础上的改进。当然，笔者不反对探索简化，但是目前探索结果还是发现，XML比较稳定，符合分离OO思想，能够健壮地对付扩展和维护。
