六,避免使用终结(finalizer)函数
原因:终结函数通常是不可预测的,一般情况下不要使用,使用的结果会带来很多问题,不稳定,性能差,移植问题等等。
分析原因:
1,从一个对象不可到达到它的终结函数被执行,这段时间是任意的,不确定的,所以时间关键的系统不应该使用终结函数。
2,及时的执行终结函数是垃圾回收算法决定的,这种算法在不同的JVM实现中会大相径庭,使用终结函数的结果就是导致移植性问题
3,如果执行终结函数的线程一直低于当前的线程的优先级,很可能造成占用大量内存,极端情况是出现OutOfMemoryError
4,JSL不保证终结函数一定被执行,所以不要依赖终结函数来更新关键性的永久状态,例如数据库的永久锁
5,不要相信System.gc() System.runFinalization这两个函数,它们只能提高终结函数的执行机会,并不保证一定执行。唯一保证一定执行的是System.runFinalizersOnExit喝Runtime.runFinalizersONExit()但这两个方法已经被声明不建议使用.
6,一个在终结函数中的一场不会打出任何信息
七:在改写equals方法的时候遵守通用约定
分析:
1,有些情况下不要随意改写equals
(1),一个类的每个实例本质上是唯一的,例如Thread
(2),不管新一个类是否提供了“逻辑相等”的测试功能,例如java.util.Random
(3),超类已经改写了equals,从超类继承过来的行为对于子类也是适合的 例如Set从AbstractSet继承了equals
(4),一个类是私有的,或者是包级私有的,并且确定它的equals方法永远不会被调用
2, 通用的约定
自反性: 对于任意的引用值x ,x.equals(x)一定为true
对称性: 对于任意的引用值x,y x.equals(y)返回true是 y.equals(x)也一定返回true
传递性:对于任意的引用值x,y,z 如果x.equals(y)返回true 并且y.equals(z)返回true 那么 x.equals(z)也一定是true
一致性:对于任意的x,y如果x,y没有被更改,调用任意多次x.equals(y)返回的结果应该一样。
非空性:对任意的引用x ,x.equals(null)一定返回false
3不要将equals声明中的Object对象换成别的类型
4,不要让equals方法依赖不可靠资源
八:改写equals方法时总要改写hashCode
原因:来自java.lang.Object关于hashCode的规范
1,在一个应用执行期间,如果一个对象的equals方法比较所用到的信息没有修改的话,那么对该对象调用hashCode多次,比如如一的返回同一个数
2,如果两个对象的equals方法返回true,那么分别调用hashCode方法返回的值应该相等
3,在两个兑现的equals方法返回false时,尽可能的让hashCode方法返回的值不相等,提高散列表的性能
分析:如果改写了equals没有改写hashCode在使用map等集合类的时候会出现问题。
九:尽可能的改写toString方法,并在显示内容中尽可能的包括令人感兴趣的信息。并且在注释中表示出你的意图。
十:谨慎的改写clone方法,改写前考虑浅拷贝和全拷贝
十一:考虑实现Comparable接口,如果你的对象要排序,那么记得实现这个方法
十二:使类和成员的可访问能力最小化,
十三:支持非可变性
非可变性遵循以下的原则:
1,不提供任何改变对象的方法
2,保证没有可被子类改写的方法
3,保证所有的域都使final
4,使所有的域都成为私有的
5,保证任何可变组件互斥访问
6,非可变对象本质是线程安全的,不需要同步
十四:复合优于继承(Think in java中有不少说明)
十五:要们专门为继承而设计,并给出文档说明,要么禁止继承
十六:接口优于抽象类(参考一下GOF的设计模式)
十七:接口只是被定义类型,不要试图使用常量接口
十八:优先考虑静态成员类
说明:嵌套类有四种
静态成员类 , 非静态成员类, 匿名类, 局部类 除了第一种之外,其它三种都被称为内部类
1,静态成员类是一种最简单的嵌套类,最好把它看成一个普通类,只是碰巧被声明在另一个类内部而已,
它可以访问外围类的所有成员,包括那些生民为私有的成员。静态成员类是外围类的一个静态成员,也遵守同样的可访问性规则,如果它被声明为私有的,那么它只能在外围类内部可以访问。静态成员类的一个用法是公有的辅助类。例如HashMap的 static class Entry
非静态成员类和静态成员类的区别主要是非静态成员类需要一个外围类实例的引用,如果你不需要访问外围类的实例的话,记得使用静态成员类。
匿名类被使用的相对多一些,但是大量的使用匿名类会让你的代码比较乱,作过GUI开发的人多会有所感触。并且记住,尽可能的让你的匿名类短小。
局部类,局部类的使用是最少的,很少会使用到这个,如果用到记得使局部类尽可能的短小
对于C语言用户的部分
十九:用类代替结构
二十:用类层次代替联合
二十一:用类来代替enum,但是在jdk1.5的时候提供了enum的支持,有些东西不一样了
二十二:用类和接口代替函数指针
二十三、在函数的开始检查参数的有效性
如果函数对参数有要求,例如不接受Null ,不接受负数等等,应该尽可能在函数的最开始给出校验,如果发现错误抛出异常
二十四、在需要的时候使用保护性拷贝
1,假设类的客户会尽一切手段来破坏这个类的约束条件,在这样的前提下,你必须保护性的设计程序。
2,实例
注意,拷贝要在检验之前进行
3,参数类型可以被不可信任方子类化的情形,清不要使用clone方法进行参数的保护化拷贝
二十五、谨慎的设计方法的原型
1,谨慎的选择方法的名字,一个好的方法名字可以让人很快记住
2,不要过于追求提供便利的方法,如果方法太多会增加使用者的学习负担,只有当一个操作被频繁使用的时候再添加一个对应的方法。
3,避免太长的参数列表,尽量让你的参数不大于三个
4,对于参数类型,优先使用接口,而不是类。
原因:如果使用接口,你可以随意的替换实现,或者同时存在多个实现。
使用类没有这个优势。
5,谨慎的使用函数对象(一个类中一堆静态函数)
二十六、谨慎的使用重载
1,实例
结果是打印出三个unknown
这个程序的行为是违反直觉的,对弈重载方法的选择是静态的,而对于被改写的方法的选择是动态的
(这个可以参考我的另一篇文章)
2,尽量不要使用两个参数数目相同的重载方法
二十七、使用零长度数组代替Null作为返回值
原因:返回Null会造成使用者每次使用的时候都要作一次判断,但有人会说返回一个零长度数组会产生new的开销,不如Null性能好。这个不是一定的,因为我们可以这样来作
private final static Cheese[] NULL_CHESE_ARRAY = new Cheese[0];
每次需要的时候返回这个数组就好了。
二十八、为所有的导出Api元素编写文档注释
二十九、使一个局部变量的作用域最小化,最好的办法使在第一次使用的时候声明
1,几乎每一个局部变量的声明都应该包含一个初始化表达式,如果你还没有足够的信息来初始化那就推迟声明。
2,for循环优先于while循环,见下边的例子
这个问题源于复制粘贴,在编码的过程中复制粘贴几乎是不可避免的,使用for循环当你出错的时候可以在编译器发生错误,而使用while则不会发现。尽早发现错误总是好的。
三十、了解和使用库(产生随机数)
详细:如果你希望产生一个位于0-某个上界的随机数,大多数的人的写法如下
这个方法存在三个缺点:
缺点一:
如果n是一个比较小的2的乘方 那么经过一段相当短的周期后它产生的随即数序列将会重复
缺点二:
如果n不是2的乘方,那么平均起来某些数比另外一些数出现的更为频繁,如果n比较大则这个问题更加显著如果产生100万范围内的随机数,你会发现数字几乎全部在0-666 666 ,前2/3的数字
缺点三:
在有些情况下会灾难性失败,返回一个落在范围之外的数字。原因是使用了Math.abs来得到一个非负数。
如果nextInt()返回 Integer.MIN_VALUE,那么abs后也会返回Integer.MIN_VALUE ,假设n不是2的乘方,那么取模操作符%将返回一个负数,这几乎肯定造成你的程序失败,而且这个失败很难重现。
为了编写一个避免上边三个缺点的random,你必须了解线性同于伪随机发生器、数论、和2的求补运算知识。不过Jdk已经实现了一个现成的可以使用,那就是Random.nextInt(int)
这一段很多比较简单,简单罗列一下,部分重要的做了解释
三十一、如果要求精确的答案,尽量避免使用float 和double,这个可以参照我的一片文章
货币尤其不合适。可以使用BigDecimal代替
三十二、如果其它类型更适合,尽量避免使用字符串
1,字符串不能替代其它的值类型
2,字符串不适合代替枚举类型
3,字符串不适合代替聚集类型
4,字符串也不是和代替能力表
因为有些时候,使用字符串会大大降低性能
三十三、了解字符串连接的性能
说明:使用StringBuffer代替 +来连接字符串
三十四、通过接口来引用对象,这能让你的程序更加灵活
三十五、接口优先于反射。
使用反射会带来很多问题,例如:
1,不能编译期发现错误
2,代码混乱
3,调试困难
4,性能损失。
除非必须,否则不使用反射
三十六、谨慎的使用本地方法JNI
三十七、谨慎的进行优化,有三条优化格言:
1,很多计算上的过失都被归咎于效率原因(没有获得必要的效率),而不是其它的原因--甚至包括盲目的作傻事. ---William A.Wulf [Wulf72]
2,不要去计较一些小的效率上的得失,在97%的情况下,不成熟的优化是一切问题的根源。
------Donald E.Knuth[Knuth74]
3,在优化方面要遵守两个原则:
规则一:不要做优化
规则二:还是不要做优化--也就是说,在你还没有绝对清晰的未优化方案前,请不要优化。
-----M.A.Jackson[Jackson75]
每次试图做优化之前和之后请对性能进行测试
三十八:遵守普遍接受的命名规则
三十九:值针对不正常的条件才使用异常,也就是说不要在正常的情况下使用异常来控制流程,活着解决某些已知的问题。因为会大量的损失性能
四十、对于可恢复的条件使用被检查的异常,对于程序错误使用运行时异常
详细:Java提供了三种可抛出结构,checked Exception, run-time exception , error
什么时候使用什么很容易让人混淆,下边是一个简单的区分原则
1,如果期望调用者能够恢复,那么对于这样的条件应该使用被检查异常
2,你所实现的所有未检查的抛出结构都是run time exception ,而不是Error
四十一:避免不必要的使用被检查异常
四十二:尽可能的使用标准异常,例如IllegalArgumentException ,NullPointerException ,IndexOutOfBoundsException等等
四十三:抛出异常要适合于相应的抽象。
高层实现应该捕获异常,同时抛出一个可以按照高层抽象解释的异常(业务逻辑上符合高层逻辑),这种做法叫做异常转译
四十四:每个方法抛出的异常都应改有文档
四十五:在细节消息中包含失败-捕获信息
详细:在异常字符串中应包含有用的信息,例如IndexOutOfBoundsException异常的细节消息应该包括下界、上界以及没有落在其中的实际下标
联系客服