我们知道注解的写法和接口很类似,都采用了关键字interface,而且都不能有实现代码,常量定义默认都是public static final类型的等,它们的主要不同点是:注解要在interface前加上@字符,而且不能继承,不能实现,这经常会给我们的开发带来一些障碍。
我们来分析一个ACL(Access Control List,访问控制列表)设计案例,看看如何避免这些障碍,ACL有三个重要元素:
资源,有哪些信息是要被控制起来的。
权限级别,不同的访问者规划在不同的级别中。
控制器(也叫鉴权人),控制不同的级别访问不同的资源。
鉴权人是整个ACL的设计核心,我们从最主要的鉴权人开始,代码如下:
interface Identifier{
//无权访问时的礼貌语
String REFUSE_WORD="您无权访问";
//鉴权
public boolean identify();
}
这是一个鉴权人接口,定义了一个常量和一个鉴权方法。接下来应该实现该鉴权方法,但问题是我们的权限级别和鉴权方法之间是紧耦合,若分拆成两个类显得有点啰嗦,怎么办?我们可以直接定义一个枚举来实现,代码如下:
enum CommonIdentifer implements Identifier{
//权限级别
Reader, Author, Admin;
//实现鉴权
public boolean identify(){
return false;
}
}
定义了一个通用鉴权者,使用的是枚举类型,并且实现了鉴权者接口。现在就剩下资源定义了,这很容易定义,资源就是我们写的类、方法等,之后再通过配置来决定哪些类、方法允许什么级别的访问,这里的问题是:怎么把资源和权限级别关联起来呢?使用XML配置文件?是个方法,但对我们的示例程序来说显得太繁重了,如果使用注解会更简洁些,不过这需要我们首先定义出权限级别的注解,代码如下:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@interface Access{
//什么级别可以访问,默认是管理员
CommonIdentifier level()default CommonIdentifier.Admin;
}
该注解是标注在类上面的,并且会保留到运行期。我们定义一个资源类,代码如下:
@Access(level=CommonIdentifier.Author)
class Foo{
}
Foo类只能是作者级别的人访问。场景都定义完毕了,那我们看看如何模拟ACL的实现,代码如下:
public static void main(Stringargs){
//初始化商业逻辑
Foo b=new Foo();
//获取注解
Access access=b.getClass().getAnnotation(Access.class);
//没有Access注解或者鉴权失败
if(access==null||!access.level().identify()){
//没有Access注解或者鉴权失败
System.out.println(access.level().REFUSE_WORD);
}
}
看看这段代码,简单、易读,而且如果我们是通过ClassLoader类来解释该注解的,那会使我们的开发更加简洁,所有的开发人员只要增加注解即可解决访问控制问题。注意看加粗代码,access是一个注解类型,我们想使用Identifier接口的identify鉴权方法和REFUSE_WORD常量,但注解是不能继承的,那怎么办?此处,可通过枚举类型CommonIdentifier从中间做一个委派动作(Delegate),委派?没看到!你可以让identify返回一个对象,或者在Identifier上直接定义一个常量对象,那就是“赤裸裸”的委派了!