1700446768
白色？这是我们添加到父类Bird上的颜色，为什么？就是因为我们在注解上加了@Inherited注解，它表示的意思是我们只要把注解@Desc加到父类Bird上，它的所有子类都会自动从父类继承@Desc注解，不需要显式声明，这与Java类的继承有点不同，若Sparrow类继承了Bird，则必须使用extends关键字声明，而Bird上的注解@Desc继承自Bird却不用显式声明，只要声明@Desc注解是可自动继承的即可。
1700446769
1700446770
采用@Inherited元注解有利有弊，利的地方是一个注解只要标注到父类，所有的子类都会自动具有与父类相同的注解，整齐、统一而且便于管理，弊的地方是单单阅读子类代码，我们无从知道为何逻辑会被改变，因为子类没有明显标注该注解。总体上来说，使用@Inherited元注解的弊大于利，特别是一个类的继承层次较深时，如果注解较多，则很难判断出是哪个注解对子类产生了逻辑劫持。
1700446771
1700446772
1700446773
1700446774
1700446776
编写高质量代码：改善Java程序的151个建议 建议91：枚举和注解结合使用威力更大
1700446777
1700446778
我们知道注解的写法和接口很类似，都采用了关键字interface，而且都不能有实现代码，常量定义默认都是public static final类型的等，它们的主要不同点是：注解要在interface前加上@字符，而且不能继承，不能实现，这经常会给我们的开发带来一些障碍。
1700446779
1700446780
我们来分析一个ACL（Access Control List，访问控制列表）设计案例，看看如何避免这些障碍，ACL有三个重要元素：
1700446781
1700446782
资源，有哪些信息是要被控制起来的。
1700446783
1700446784
权限级别，不同的访问者规划在不同的级别中。
1700446785
1700446786
控制器（也叫鉴权人），控制不同的级别访问不同的资源。
1700446787
1700446788
鉴权人是整个ACL的设计核心，我们从最主要的鉴权人开始，代码如下：
1700446789
1700446790
interface Identifier{
1700446791
1700446792
//无权访问时的礼貌语
1700446793
1700446794
String REFUSE_WORD=“您无权访问”；
1700446795
1700446796
//鉴权
1700446797
1700446798
public boolean identify（）；
1700446799
1700446800
}
1700446801
1700446802
这是一个鉴权人接口，定义了一个常量和一个鉴权方法。接下来应该实现该鉴权方法，但问题是我们的权限级别和鉴权方法之间是紧耦合，若分拆成两个类显得有点啰嗦，怎么办？我们可以直接定义一个枚举来实现，代码如下：
1700446803
1700446804
enum CommonIdentifer implements Identifier{
1700446805
1700446806
//权限级别
1700446807
1700446808
Reader, Author, Admin；
1700446809
1700446810
//实现鉴权
1700446811
1700446812
public boolean identify（）{
1700446813
1700446814
return false；
1700446815
1700446816
}
1700446817
[
上一页 ]
[ :1.700446768e+09 ]
[
下一页 ]