Effective Java其他碎片建议3

本文探讨了Java中泛型和集合的高效使用方法,包括优先选择泛型和列表而非数组,避免使用原生态类型,以及如何正确处理非受检警告等。还介绍了如何通过泛型方法和有限制通配符提升API的灵活性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Rule 21、用函数对象表示策略

这篇文章之前写过,详细见这里。




Rule 22、优先考虑静态成员类

嵌套类(nested class)是定义在另一个类内部的类,目的应该置为它的外围类(enclosing class)提供服务,如果将来会用于其他的某个环境中,他就应该是顶层类(top-level class)。嵌套类有四种:静态成员类(static member class)、非静态成员类(nonstatic member class)、匿名类(anonymous class)和局部类(local class)。除了第一种之外,其他类都被称为内部类(inner class)。

如果成员类的每个实例都需要一个指向其外围实例的引用,就要把成员类做成非静态的,否则就做成静态的。假设这个嵌套类属于一个方法的内部,如果你只需要要一个地方创建实例,并且已经有一个预置的类型可以说明这个类的特征,就把他做成匿名类,否则做成局部类。




Rule 23、请不要在新代码中使用原生态类型

在java1.5版本时增加了泛型(Generic)。我们将申明了一个或者多个类型参数的类或者接口称为泛型,在没有泛型之前,在集合中读到的每一个对象都需要进行类型转换,如果不小心插入了类型错误的对象,运行时就会报错,但是有了泛型之后,可以告诉编译器每个集合中允许接受哪些类型的对象。(因此泛型仅仅停留在编译阶段,至于如何使用反射跳过编译阶段泛型的检查,请参考这篇文章)。每个泛型都定义一个原生态类型(raw type),如List<E>的原生态类型就是List。

如果使用原生态类型就失掉了泛型在安全性和表示性方面的有时,java仍然支持原生态类型仅仅是为了兼容性。

另外如果不确定或者不关心实际的参数类型,可以用一个?代替泛型中的类型参数,例如Set<E>的无限制通配符类型为Set<?>,读作某个类型的集合。

然而这条规则有两个例外,

第一、在类类型(class literal 原文翻译为类文字,可是我觉得类类型要广为人知一点)中必须使用原生态类型。换句话说List.class是合法的,但是List<?>.class和List<Integer>.class都是不合法的。

第二、由于泛型信息可以在运行时擦除,因此在参数化类型而非无限制通配符上使用instanceof操作符是非法的。在使用无限制通配符类型代替原生态类型对instanceof操作符不会产生仍和影响,在这种情况下<>和?就显得多余了。但是这样的情况下我还是想用泛型来使用instanceof怎么办呢:

if(o instanceof Set){//原生态类型
    Set<?> m = (Set<?>) o;
}
这是Effective Java指出利用泛型来使用instanceof操作符的首选方法,一旦确定这个o是Set,就需要把他转化为通配符类型Set<?>,而不是转化成原生态类型。

总之,使用原生态类型会在运行是导致异常,请不要在新代码中使用。原生态类型只是为了与引入泛型之前的遗留代码互相兼容而提供的。

Set<Object>是个参数化类型表示可以包含任何对象类型的一个集合;

Set<?>是一个通配符类型,表示只能包含某种位置对象类型的一个集合;

Set是一个原生态类型,脱离了泛型系统,前两种是安全的,最后一种不安全;

请不要在新代码中使用原生态类型,除非在需要使用类类型和instanceof的情况下。




Rule 24、消除非受检警告

在使用泛型编程的时候,会遇到很多编译器非受检警告。

如果无法消除警告,同时可以证明引起警告的代码是类型安全的,只有在这种情况下,才可以用一个@SuppressWarnings("unchecked")注解来禁止这条警告。如果没有证明相应代码是安全的,那这只是一种错误的安全感。

@SuppressWarnings注解可以用在任何粒度的级别中,从单个局部变量到整个类。但是永远不要在整个类上使用@SuppressWarnings,这样做可能会掩盖了重要的警告。

使用@SuppressWarnings注解的时候,需要添加一行注释,说明为什么这段代码是类型安全的。




Rule 25、列表优于数组

数组和泛型相比,有两个重要的不同点。


首先,数组是协变的(convariant),而泛型是不可变的(invariant)。

对于任意两个不同的类型type1和type2,无论type1和type2有无继承关系,List<type1>和List<type2>都不存在继承关系,而数组不是这样的。这可能有些难理解,看一段代码:

Object[] objArr = new Long[1];
objArr[0] = "我放不下这个数组";
上面这段代码不会有编译错误,因为Long是Object类的子类,但是会有运行时错误(Throws ArrayStoreException)。
当我们使用列表就不会出现这样的情况:

List<Object> l = new ArrayList<Long>();//报错
l.add("我放不下这个数组");
在编译阶段就报错了,而不是想数组一样到运行的时候才报错。


数组和使用泛型的列表的第二个区别在于,数组时具体化的(reified)。因此数组会在运行时才知道并检查他们的元素类型约束。比如上面的代码,将String保存到Long数组中,只有运行时才会报错。相对的,泛型是通过擦除(erasure)来实现的。因此泛型只在编译时强化他们的类型信息,在运行时进行丢弃(或者说擦除)他们的元素类型信息。擦除就是使泛型可以和没有使用泛型的代码进行互用。因此数组和泛型不能很好地混合使用。

下面这些表达式都是非法的

new List<E>[]、 new List<String>[]、 和new E[]都是非法的。

为什么创建泛型数组是非法的?因为它不是类型安全的。




Rule 26、优先考虑泛型

比如自己写一个Stack类,尽量给他泛型化,写成Stack<E>。

使用泛型比使用需要在客户端代码中进行转换的类型来得更加安全,也更容易。只要时间允许,把现有的类型都泛型化。这对于这些类型的用户会变得更加轻松,又不会破坏现有的客户端。




Rule 27、优先考虑泛型方法

泛型方法就像泛型一样,使用起来比要求客户端转换输入参数并返回值的方法来得更加安全,也更容易。就像类型一样。应该确保新方法可以不用转换就能使用,这通常意味着要将他们泛型化。




Rule 28、利用有限制通配符来提升API的灵活度

就像之前说的,类型化参数是不可变的(invariant),也就是对于Type1和Type2而言,哪怕Type1是Type2的子类,List<Type1>也不是List<Type2>的子类,这与直觉相悖,但是实际上很有意义。

有时候,我们需要的灵活性要比不可变类型所能提供的更多。这个时候就可以用到有限制通配符:比如putAll(Set<? extends E> );或者putAll(Set<? super E>);分别表示参数的参数类型分别是E的某个子类或者E的某个超类。

总之,如果要编写将被广泛使用的类库,则一定要适当利用通配符类型。记住基本的原则:PECS(Producer-extends,Customer-super)。

1. 用户与权限管理模块 角色管理: 学生:查看实验室信息、预约设备、提交耗材申请、参与安全考核 教师:管理课题组预约、审批学生耗材申请、查看本课题组使用记录 管理员:设备全生命周期管理、审核预约、耗材采购与分发、安全检查 用户操作: 登录认证:统一身份认证(对接学号 / 工号系统,模拟实现),支持密码重置 信息管理:学生 / 教师维护个人信息(联系方式、所属院系),管理员管理所有用户 权限控制:不同角色仅可见对应功能(如学生不可删除设备信息) 2. 实验室与设备管理模块 实验室信息管理: 基础信息:实验室编号、名称、位置、容纳人数、开放时间、负责人 功能分:按学科(计算机实验室 / 电子实验室 / 化学实验室)标记,关联可开展实验类型 状态展示:实时显示当前使用人数、设备运行状态(正常 / 故障) 设备管理: 设备档案:名称、型号、规格、购置日期、单价、生产厂家、存放位置、责任人 全生命周期管理: 入库登记:管理员录入新设备信息,生成唯一资产编号 维护记录:记录维修、校准、保养信息(时间、内容、执行人) 报废处理:登记报废原因、时间,更新设备状态为 "已报废" 设备查询:支持按名称、型号、状态多条件检索,显示设备当前可用情况 3. 预约与使用模块 预约管理: 预约规则:学生可预约未来 7 天内的设备 / 实验室,单次最长 4 小时(可设置) 预约流程:选择实验室→选择设备→选择时间段→提交申请(需填写实验目的) 审核机制:普通实验自动通过,高危实验(如化学实验)需教师审核 使用记录: 签到 / 签退:到达实验室后扫码签到,离开时签退,系统自动记录实际使用时长 使用登记:填写实验内容、设备运行情况(正常 / 异常),异常情况需详细描述 违规管理:迟到 15 分钟自动取消预约,多次违规限制预约权限 4. 耗材与安全管理模块 耗材管理: 耗材档案:名称、规格、数量、存放位置、
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值