注解

简介: 注解是JAVA5引入JAVA的一个特性,理解起来会有点抽象,这里笔者先给出自己对注解的一个理解——注解就是一张便签!其次要有一个概念就是注解的应用是基于反射的。本文举出的三个实例中例1和例3是引用其它的优秀文献出处为how2J以及 https://blog.csdn.net/briblue/article/details/73824058一文

基础注解

JDK中有几个基本内置注解,基本注解就是JAVA已经封装好了的注解,拿来用就是。

其实基础注解除了@Override和@Deprecated会偶尔用到以外,其他几个基本不会用到意义不大,看个热闹就是。

最重要的还是元注解。

@Override

表示方法重写

@Deprecated

表示方法以及过期,下个版本可能被删掉。

2019081116585142.png

@SuppressWarnings

用于抑制告警

比如@SuppressWarnings({ "rawtypes", "unused" })用于抑制泛型未声明的告警。


@SuppressWarnings 有常见的值,分别对应如下意思


1.deprecation:使用了不赞成使用的类或方法时的警告(使用@Deprecated使得编译器产生的警告);


2.unchecked:执行了未检查的转换时的警告,例如当使用集合时没有用泛型 (Generics) 来指定集合保存的类型; 关闭编译器警告


3.fallthrough:当 Switch 程序块直接通往下一种情况而没有 Break 时的警告;


4.path:在类路径、源文件路径等中有不存在的路径时的警告;


5.serial:当在可序列化的类上缺少 serialVersionUID 定义时的警告;


6.finally:任何 finally 子句不能正常完成时的警告;


7.rawtypes 泛型类型未指明


8.unused 引用定义了,但是没有被使用


9.all:关于以上所有情况的警告。

@SafeVarargs

这是1.7 之后新加入的基本注解. 如例所示,当使用可变数量的参数的时候,而参数的类型又是泛型T的话,就会出现警告。 这个时候,就使用@SafeVarargs来去掉这个警告。

元注解

元注解是JAVA专门留给开发者自定义注解使用的,也就是可以用在注解中的注解。

@Target

@Target 表示这个注解允许被放在什么位置


ElementType.TYPE:能修饰类、接口或枚举类型


ElementType.FIELD:能修饰成员变量


ElementType.METHOD:能修饰方法


ElementType.PARAMETER:能修饰参数


ElementType.CONSTRUCTOR:能修饰构造器


ElementType.LOCAL_VARIABLE:能修饰局部变量


ElementType.ANNOTATION_TYPE:能修饰注解


ElementType.PACKAGE:能修饰包

@Retention

@Retention用来声明生命周期

 

RetentionPolicy.SOURCE:源码阶段

RetentionPolicy.CLASS: 编译阶段

RetentionPolicy.RUNTIME:运行阶段

@Inherited

表示注解可以被子类继承。即子类继承父类以后,也可以继承父类的注解。

@Documented

表示生成API

@Repeatable

表示注解在同一个地方可以出现多次,如果不加这个注解的话,同一个地方注解只能出现一次。

自定义注解

关于自定义注解说起来很简单,用@interface修饰起来,然后各种元注解,一个自定义的注解就产生了。

但用起来却很有学问——注解到底用在什么地方?这个问题其实是没有标准答案的,注解就像一张便签纸,你想把它贴在哪里都可以,而且根据便签上的内容的不同,这张便签起到的作用也不同。这里举两个自定义注解的例子,来和大家一起找找感觉,打开一下思路,看看注解应该用在什么地方。

例1

注解用来存放变量。

20190811170749480.png

20190811171133143.png

例2

注解用来做分类判断

为一个People贴上一张MyComponent的标签,那这个people就会被分到MyComponent这分类中去。就像我们生活中贴上好人的标签,大众就把你归类为好人,贴上坏人的标签大众就把你归类为坏人是一个道理。


至于为什么不抽象出一个MyComponent让P类去实现它,然后判断类是不是MyComponent.class类型?


问题是这种模式只能作用于类层面,无法作用于方法层面,而注解就可以办到。


仔细想想Spring体系中的注解开发是不是就是这个原理??

20190811173908708.png

20190811173924100.png

20190811173941482.png

20190811173953174.png

例3

其实例3就是结合了例1和例2,实例代码很简单,就是一个注解版的hibernate类

每一个属性单独抽象出一个注解,注解里面就存放一个属性就OK。

20190811174915428.png

目录
相关文章
|
7月前
|
Java 数据库连接 数据库
什么时候用@MapperScan 注解?
什么时候用@MapperScan 注解?
239 0
|
Java 测试技术 Spring
关于@RunWith注解的一点问题
IDEA写springboot测试关于@Runwith的小问题
255 0
关于@RunWith注解的一点问题
|
Java 编译器
关于@FunctionalInterface注解
FunctionalInterface
473 0
关于@FunctionalInterface注解
|
Java 编译器 Spring
什么是注解
什么是注解
|
Java 编译器 Spring
|
XML Dubbo Java
duboo注解使用详解
当越来越的的接口与实现类的增加后,duboo的xml配置会越来越多,为了防止几百几千行的代码,减少开发人员配置xml的工作量,使用duboo的注解模式,减少配置多出问题多的可能性!
174 0
duboo注解使用详解
|
缓存
扒一扒@Retryable注解,很优雅,有点意思! (2)
扒一扒@Retryable注解,很优雅,有点意思! (2)
320 0
扒一扒@Retryable注解,很优雅,有点意思! (2)
|
Java 程序员 开发工具
扒一扒@Retryable注解,很优雅,有点意思! (1)
扒一扒@Retryable注解,很优雅,有点意思! (1)
381 0
扒一扒@Retryable注解,很优雅,有点意思! (1)
|
Java Maven
扒一扒@Retryable注解,很优雅,有点意思! (5)
扒一扒@Retryable注解,很优雅,有点意思! (5)
274 0
扒一扒@Retryable注解,很优雅,有点意思! (5)
下一篇
DataWorks