首页 > 代码库 > JAVA注解引发的思考
JAVA注解引发的思考
自从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的源码了,欢迎讨论。
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。