改善Java程序的151个建议 1-5章
文章目录
建议1:不要在常量和变量中出现易混淆的字母
建议2:莫让常量蜕变成变量
RAND_CONST是常量吗?它的值会变吗?绝对会变!这种常量的定义方式是极不可取的,常量就是常量,在编译期就必须确定其值,不应该在运行期更改,否则程序的可读性会非常差,甚至连作者自己都不能确定在运行期发生了何种神奇的事情。
建议3:三元操作符的类型务必一致
三元操作符类型的转换规则
- 若两个操作数不可转换,则不做转换,返回值为Object类型。
- 若两个操作数是明确类型的表达式(比如变量),则按照正常的二进制数字来转换,int类型转换为long类型,long类型转换为float类型等。
- 若两个操作数中有一个是数字S,另外一个是表达式,且其类型标示为T,那么,若数字S在T的范围内,则转换为T类型;若S超出了T类型的范围,则T转换为S类型(可以参考“建议22”,会对该问题进行展开描述)。
- 若两个操作数都是直接量数字(Literal[插图]),则返回值类型为范围较大者。
建议4:避免带有变长参数的方法重载
变长参数的优缺点
- 可以提高方法的灵活度和可复用性
- Java5之前常用的设计技巧就是把形参定义成Collection类型或子类类型,或者数组类型
- 缺点:需要对空参数进行判断和筛选,比如参为null值和长度为0的Collection或数组
- *:Java5以后引入变长参数
变长参数定义规则
- 变长参数必须是方法中的最后一个参数
- 一个方法不能定义多个变长参数
重载的定义
方法名相同,参数类型或数量不同
错误示例
问题在:
变长参数的范围覆盖了非变长参数的范围
提问
对于calPrice(49900,75)这样的计算,到底该调用哪个方法来处理呢?
改善建议:
问题是阐述清楚了,为了让我们的程序能被“人类”看懂,还是慎重考虑变长参数的方法重载吧,否则让人伤脑筋不说,说不定哪天就陷入这类小陷阱里了。
建议5:别让null值和控制威胁到变长方法
问题代码
问题是
- 两处提示是相同的:方法模糊不清,编译器不知道调用哪一个方法
- 但是两处代码反应的代码味道可是不同的
问题在
- 对于methodA(“China”)方法,是Client类的设计者,违反了KISS原则(Keep It Simple,Stupid,即懒人原则),按照此规则设计的方法应该很容易被调用。调用者调用methodA(“China”)是符合规范的,但是现在却出错了,因为两个方法都符合形参格式,编译器不知道调用哪个方法。
- 对于client.methodA(“china”,null)方法,直接量null是没有类型的。虽然两个方法都符合调用请求,但是不知道调用哪个,于是报错了。
- 出错有:不符合懒人原则
- 还有一个非常不好的编码习惯:即调用者隐藏了实参类型,这是很危险的,不仅调用者需要猜测该调用哪个方法,而且被调用者也可能产生内部逻辑混乱的情况
- 对于本例来说,应做如下修改:
隐藏了实参类型,这是很危险的,不仅调用者需要猜测该调用哪个方法,而且被调用者也可能产生内部逻辑混乱的情况 - 对于本例来说,应做如下修改: