JAVA注解引发的思考
浏览数：25 /
时间：2015年06月08日
自从JDK1.5引入@override，@Deprecated，@SuppressWarnings这三个注解和自定义注解后，注解开始如火如荼地发展起来，现在很多框架都支持注解，注解可以使我们的代码看起来更简洁，而且在一定程度上解除了类原有特性和扩展特性之间的耦合。
为什么加上@Override，当前的方法就定义将覆盖超类中的方法，如果不覆盖就编译报错？
为什么使用加上@Deprecated的，编译器将发出警告，这是弃用的代码？
为什么加上@SuppressWarnings，编译器就不再发出警告信息？
为什么我说：注解可以使我们的代码看起来更简洁，而且在一定程度上解除了类原有特性和扩展特性之间的耦合？
不知道从什么时候，我开始讨厌往博客上贴大片的代码，还是不想贴，但要说明这几个问题，还是不得不用代码说事。
我们来写一个注解，你就明白怎么回事了。
我们来仿照@Deprecated，写一个极简的@MyDeprecated吧，实现的效果和@Deprecated一样。
package com.jialin.test.annotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
/**
* @Author : JiaLin
* @Group : TGB
* @Date : 2014/6/9
* @Description :
*/
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyDeprecated {
public String description() default "Warning:This method is Deprecated!";
}
对以上元注解（元注解，说白了就是注解的注解）的简要说明
|
@Target |
表示该注解可以用于什么地方，可能的ElementType参数有： CONSTRUCTOR：构造器的声明 FIELD：域声明（包括enum实例） LOCAL_VARIABLE：局部变量声明 METHOD：方法声明 PACKAGE：包声明 PARAMETER：参数声明 TYPE：类、接口（包括注解类型）或enum声明 |
|
@Retention |
表示需要在什么级别保存该注解信息。可选的RetentionPolicy参数包括： SOURCE：注解将被编译器丢弃 CLASS：注解在class文件中可用，但会被VM丢弃 RUNTIME：VM将在运行期间保留注解，因此可以通过反射机制读取注解的信息。 |
|
@Document |
将注解包含在Javadoc中 |
|
@Inherited |
允许子类继承父类中的注解 |
package com.jialin.test.annotation;
import java.lang.reflect.Method;
/**
* @Author : JiaLin
* @Group : TGB
* @Date : 2014/6/9
* @Description :
*/
public class MyClass {
@MyDeprecated
public String sayHelloWorld()
{
return "Hello,World!";
}
public String sayHelloJiaLin()
{
return "Hello,Jialin!";
}
public static void main(String[] args) {
testMyDeclared(MyClass.class);
}
public static void testMyDeclared(Class<?> myClass) {
for (Method method : myClass.getDeclaredMethods()) {
MyDeprecated myDeprecated = method.getAnnotation(MyDeprecated.class);
if (myDeprecated != null) {
System.out.println(myDeprecated.description()+method.getName());
}
}
}
}
输出结果：Warning:This method is Deprecated! sayHelloWorld
看了代码，相信文章开头那几个问题就不用过多解释了。
其实，之所以会研究注解，也是由于我最近一直在想怎么让项目的很多地方解耦合，注解就是其中一个不错的方法，例如同一个查询方法，加上不同的注解，它查询的表就不一样或者说结果就不一样。
结合上枚举，反射和拦截器，我们就可以达到这样的效果。还是一种延时注入的思想，思路如下：我们开辟一个静态区域作为容器，然后存放我们的枚举值，然后利用拦截器拦截到要执行的方法，通过反射获取这个方法的注解，然后将注解的属性与我们的枚举值匹配，如果匹配成功，那么修改方法的参数。
写到这，我忽然意识到，Spring的IOC容器大概也是这么个思路，看样子是时候好好读读spring的源码了，欢迎讨论。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
