首页 > 代码库 > Annotation(一)——注解开发介绍
Annotation(一)——注解开发介绍
在编程中,一直强调的一点就是注释的编写,注释的规范等等。尤其是越是核心,程序越复杂,逻辑越多的清空下,注释的编写对我们以后的阅读代码,维护软件起着至关重要的作用。一款软件有着好的注释,相当于一个中国人阅读一篇带着汉语翻译的英文文章,其阅读速度是事半功倍的效果。但是今天想要总结的却不是代码中的注释需要注意的问题,而是JDK5.0以后提供的一种新特性。
一, Annotation(注解),其实就是对类,方法,属性进行的一种标示,一种注释(注意,这个里注释不是为了让我们开发或维护人员阅读更方便,而是为JVM看呢),通过这些标示,Java虚拟机可以完成这些标示对应的功能。例如使用框架开发时,我们都是通过配置文件进行对象关系组合映射等功能,而通过注解我们可以完全代替配置文件的编写。
二,Annotation的作用:
编写文档:通过代码里标识的元数据生成文档。
代码分析:通过代码里标识的元数据对代码进行分析。
编译检查:通过代码里标识的元数据让编译器能实现基本的编译检查。
三,JDK内置的几个常用注解:
1,@Override:此注解能够实现编译时检查,当某方法前边添加此注解时,表示此方法为重写父类中的方法。如果此方法不是父类的方法,例如我们本来想重写toString呢,却写成了tostring,则编译无法通过,会提示错误。
2,@Deprecated:此注解是对不应该,或者将要淘汰的方法进行标识,当编程人员使用时就会给予提示。这个功能在一些基础jar包,规范,框架等的中我们经常可以看到,还保留这些方法是为了兼容前边的一些版本,有一过度的阶段。看下边的这种效果应该都见过:
3,@SuppressWanings:此注解表示去除一些警告,但是里边需要我们制定参数,我们来看一下一些常用的参数:
参数名称 | 参数解释 |
Unused | 没有被访问过的元素,去除警告 |
Unchecked | 执行了未检查的转换时的警告,例如当使用集合时没有用泛型来指定集合保存的类型 |
Fallthrough | 当Switch程序块直接通往下一种情况二没有Break时的警告 |
Path | 在类路径,源文件路径等中有不存在的路径时的警告 |
Serial | 当在可序列化的类上缺少serialVersionUID定义时的警告 |
Finally | 任何finally子句不能正常完成时的警告 |
All | 关于上边所有情况的警告 |
4, 当然我们也可以通过@interface进行自定义注解的定义,我们可以像@SuppressWanings一样向里边添加参数,利用@Target注解来指定其使用范围;@Documented表示此注解是否文档化,就是当我们生成文档时,是否生成进去;@Inherited标注继承,控制此注释是否会影响到子类等等。看一下自定注解的简单例子:
@Target({ElementType.METHOD,ElementType.CONSTRUCTOR})
@Documented
@Inherited
public@interfaceNewAnnotation {
String value();//在写注解的时候value参数中value=http://www.mamicode.com/可以省略,其它参数名不能省
}
也就是说后边这几个注解是用来给注解做注解的,也就是注解的注解。当然了这些JDK为我们提供的一些常见的注解。而在实际开发中我们都是通过对类,对方法添加注解来代替配置文件的编程,从而从开发效率上大大提高了。
最后看一下通过注解开发和配置文件开发的对比吧:
配置文件的开发 | 注解方式开发 | |
优点 | 1,遵循OCP开发原则,修改配置文件即可进行功能扩展 2,集中管理对象和对象之间的组合关系,易于阅读 | 1,开发速度快 2,编译期间容易发现错误的出处 |
缺点 | 1,开发速度相对较慢; 2,编译时很难检查出错误,运行中的错误很难定位,调试难度较大。 | 1,管理分散,基本每个类上都有; 2,扩展功能时,没有遵循OCP开发原则。 |
何时选择 | 如果客户需求进行发生变化,那么采用配置文件的方式会好一些。有利于扩展。 | 如果客户需求不会频繁发生变化。那么使用注解非常好,开发效率快 |
总而言之,注解开发是当今的一个开发趋势,因为它的开发效率高,谁都想着在最短的时间内创造最大的价值。但是使用还需慎重考虑,根据实际情况进行选择。这里简单介绍了注解的基础,下边主要将在使用框架开发中,如何利用注解帮助我们提高效率。
Annotation(一)——注解开发介绍