【论题】+【方案】注解 VS 配置文件

哑鸟 发布于 2013/05/22 13:59
阅读 346
收藏 1

论题时间:

2012-11-22

论题参与:

java 技术群(3 年以上) 95379959,所有成员

论题内容:

注解 VS 配置文件,谈谈你的认识;

方案一:

方案人:

方案内容:

注解(Annotation)是 JDK5.0 及以后版本引入的。它可以用于创建文档,跟踪代码中的

依赖性,甚至执行基本编译时检查,内建 3 个 Annotation:@Override、@Deprecated、

@SuppressWarnings,然而最新的理论收将所有的配置直接写入到程序之中。

@Override:用@Override 表示一个方法声明打算重写超类中的另一个方法声明。

@Deprecated 不推荐使用的元素,注释的程序元素,通常是因为它很危险或存在更好的选

择。

@SuppressWarnings:@SuppressWarnings("deprecation")指示应该在注释元素(以及

包含在该注释元素中的所有程序元素)中取消显示指定的编译器警告。

1.注解的原理与使用;

2.Java 提供的标准注解分析;

3.常见框架使用注解,如 Spring 的 MVC 内的使用;

4.如何合理的设计和使用注解;

注解的原理和使用:

注解是以‘@注解名’在代码中存在的,根据注解参数的个数,我们可以将注解分为:标

记注解、单值注解、完整注解三类。它们都不会直接影响到程序的语义,只是作为注解(标

识)存在,我们可以通过反射机制编程实现对这些元数据的访问。另外,你可以在编译时选

择代码里的注解是否只存在于源代码级,或者它也能在 class 文件中出现。

Annotation 其实是一种接口,可以参阅 JDK 文档帮助,具体方式实现不变详细述说,

其方式是通过 java 的反射机制相关的 API 来访问 Annotation 信息。相关类根据这些信息来

决定如何使用该程序元素或改变它们的行为,通过预先定义然后,Java 语言解释器在工作

时会忽略这些 Annotation,因此在 JVM 中这些 Annotation 是“不起作用”的,只能通过配套

的工具才能对这些 Annotation 类型的信息进行访问和处理,其实说简单就是预先定义后,

通过其他方式的辅助然后运用,起到程序访问的结果。

如@Override 注解表示子类要重写父类的对应方法

以下是针对@Override 的实例:

     首先、定义注解类,格式为:

public @interface A{ }

其次、应用注解类,如:

@A

     class B{ }

     然后、应用注解类的类进行反射操作,如:

B.class.isAnnotationPresent(A.class);

A a = B.class.isAnnotationPresent(A.class);

     Annotation 类型的方法必须声明为无参数、无异常抛出的。这些方法定义了 annotation

的成员:方法名成为了成员名,而方法返回值成为了成员的类型。而方法返回值类型必须为

primitive 类型、Class 类型、枚举类型、annotation 类型或者由前面类型之一作为元素的一维

数组。方法的后面可以使用 default 和一个默认数值来声明成员的默认值,null 不能作为成

员默认值,这与我们在非 annotation 类型中定义方法有很大不同。

Annotation 类型和它的方法不能使用 annotation 类型的参数、成员不能是 generic。只有

返回值类型是 Class 的方法可以在 annotation 类型中使用 generic,因为此方法能够用类转换

将各种类型转换为 Class。

应用场景:

annotation 一般作为一种辅助途径,应用在软件框架或工具中,在这些工具类中根据不

同的 annontation 注解信息采取不同的处理过程或改变相应程序元素(类、方法及成员变量

等)的行为。(引用)

元注解@Target,@Retention,@Documented,@Inherited

* @Target 表示该注解用于什么地方,可能的 ElemenetType 参数包括:

*

*

*

*

*

*

*

*

*

*

*

ElemenetType.CONSTRUCTOR 构造器声明

ElemenetType.FIELD 域声明(包括 enum 实例)

ElemenetType.LOCAL_VARIABLE 局部变量声明

ElemenetType.METHOD 方法声明

ElemenetType.PACKAGE 包声明

 ElemenetType.PARAMETER 参数声明

 ElemenetType.TYPE 类,接口(包括注解类型)或 enum 声明

@Retention 表示在什么级别保存该注解信息。可选的 RetentionPolicy 参数包括:

 RetentionPolicy.SOURCE 注解将被编译器丢弃

RetentionPolicy.CLASS 注解在 class 文件中可用,但会被 VM 丢弃

RetentionPolicy.RUNTIME VM 将在运行期也保留注释,因此可以通过反射机制读取注

解的信息。

* @Documented 将此注解包含在 javadoc 中

* @Inherited 允许子类继承父类中的注解

注解的应用:

较为常用的 Spring 的 MVC 框架的应用、Hibernate 注解的应用、Struts、Spring 等主流的

框架应用中广泛使用了 annontion,应用项目的场景大大提高了开发效益和质量,提高代码

的灵活度;

注解谈及太多,也只是意会不可言传,能在常用框架中,记住常用的注解使用方式,明

白常用注解的处理过程,知晓自定义注解的应用,便是对注解良好的认识了,因此谈及内容

较少涉及实现、以及具体源码,网上源码和实现也是较多,此处也不便抛出,只是以不同的

角度,去认识相同的事物,当然一种方式有利也有弊,利弊取舍还是取决于项目中的实际开

发场景。

方案二:

方案人:

北京-零度 J-4 年(469102165)

方案内容:

认识:

注解:

利:

1、 无需工具支持,无需解析

2、 编译期即可验证正确性,查错变得容易

3、 开发效率

弊:

1、 注解是写在代码里面的,配置信息不集中,不方便更改;若要对配置项进行修改,不

得不修改 Java 文件,重新编译打包应用可扩展性差;

2、 .注解是通过反射解析,有些复杂配置的实现不如通过配置文件容易实现

3、 annotation 比较难维护,但一个项目维护是占很大地位的,并且现在习惯先设计表,

然后设计类什么的,很多 IDE 都能自动生成 xml 配置文件,

配置文件:

弊:

1、 需要解析工具或类库的支持,

2、 IDE 无法验证配置项内容的正确性,查错很困难

3、 解析 xml 势必会影响应用程序性能,占用系统资源

4、 开发人员不得不同时维护代码和配置文件,开发效率低下

利:

1、 xml 作为可扩展标记语言,最大的优势在于开发者能够为软件量身定制适用的标记,

使代码更加通俗易懂。

2、 可扩展性强

3、 修改配置而无需变动现有程序,维护性好

4、 利用 Schema 或 DTD 可以对 xml 的配置标签的正确性进行验证,避免非法配置

建议考虑:

1、 需要经常改动的地方用 xml,比如数据源的配置;

2、 不需要修改或是不经常修改的地方用注解,比如事务处理。

3、 性能要求很高的地方,优先考虑配置文件。

4、 团队合作中,可以优先考虑 注解






























加载中
返回顶部
顶部