Effective Java 笔记（九）

最新推荐文章于 2024-10-06 14:20:39 发布

ilibaba

最新推荐文章于 2024-10-06 14:20:39 发布

阅读量1.2k

点赞数

分类专栏： JAVA开发应用笔记（读书、心得）文章标签： java vector integer null string float

本文链接：https://blog.csdn.net/ilibaba/article/details/4207511

版权

JAVA开发应用同时被 2 个专栏收录

50 篇文章 0 订阅

订阅专栏

笔记（读书、心得）

30 篇文章 1 订阅

订阅专栏

相关读书笔记列表

NO.27 返回零长度的数组而不是null
    如果返回null，对于每次调用到该方法的时候都需要做null判断，否则很容易抛出空指针异常，推荐返回一个零长度的数组，在通常情况下，这样的做法对性能几乎没有影响。

NO.28 为所有导出的API元素编写文档注释
需要增加注释的地方：类、接口、构造函数、方法和域声明，方法注释的内容：
调用该方法的前提条件；
调用后的后续处理（如捕获异常）；
副作用（如方法启动线程后带来的安全性）；
参数@param Describe；
返回@return Describe；
异常@throws if.....；
注意：注释中可以适用<p><code><tt>等HTML标签，但>,<等标签需要转义。

NO.29 讲局部变量的作用域最小化
在第一次适用局部变量的地方声明他；
要防止局部变量在“使用它的块”之外声明，这样会防止局部变量被意外使用；
几乎每一个局部变量的需要初始化，如果没有足够的信息来对一个变量进行有意义的初始化，那就推迟这个声明，直到可以初始化为止；
其他的方法如，把一个变量多的方法分成两个，每次操作一个方法，减少变量之间的干扰。

NO.30 了解和使用库
    不要从头发明轮子，如果你要做的事情是很常见的，就去查下有没有这样的实现类，如果有，则使用它，这样会降低你实现相应功能的投入和代码的出错率。

NO.31 如果要求精确的答案，请避免使用 float和 double
      float和 double不适合表示货币，在平时的使用中应该避免；如果希望系统来处理十进制的小数点，可以使用 BigDocimal,如果不考虑小数的处理，数值范围没有超过 9位的则可以用 int来处理，如果不超过 18位的，则可以用 long来处理，超过 18位的就必须用 BigDecimal处理。

NO.32 如果其他类型更适合，则尽量避免使用字符串
    如果可以使用更加合适的数据类型，或者可以编写更加恰当的数据类型（如 DO、 POJO、枚举等），那么应该避免使用字符串来表示对象，若使用不当，字符串比其他类型更加笨拙，缺乏灵活性。

NO.33 了解字符串连接的性能
    为连接 N个字符串而重复得地使用“ +”连接，要消耗 N的平方级别的时间。为了获得更高的性能，请使用 StringBuffer代替 String。

NO.34 通过接口引用对象
    应该优先使用接口而不是类来引用对象，如果有合适的接口存在，那么对参数的返回值、变量和域的声明都应该使用接口类型，如 Vector是 List接口的实现，在声明时应该如下：
List subscribers = new Vector(); //而不是 Vector subscribers = new Vector();
例外的情况：

① 当没有合适的接口存在，可以用类而不是接口来引用一个对象，如： String、 Integer；

② 当一个对象是基本类型的类，而不是接口时，应该用相关的基类引用这个对象，如： java.util.TimerTask;

③ 当一个类实现了一个接口，单它提供了接口中不存在的额外方法，如果程序依赖于这些额外的方法，那么这样的类应该只被用来引用它的实例，永远不应该被用作参数类型。

NO.35 接口优先于映像机制（反射机制）
    反射机制是 Java一项强大的功能，对于一些特定复杂的程序设计中非常必要（如现在很流行的 spring框架），但在并非必须使用反射机制时，尽量避免使用反射,原因如下：
     ① 它在编译时不会进行类型检查；
     ② 实现代码冗长乏味，不易阅读；
     ③ 性能与一般的方法调用相比，要低下很多；
    如果一个程序必须要与编译时未知的类一起工作，那么最好是用反射实例化对象，而访问对象时使用编译时刻已知的某个接口或者父类。

NO.36 谨慎地使用本地方法
    尽量使用 Java自身提供的方法来代替本地方法（如用 Java提供的新功能来代替以前只有 C语言能实现个的功能），这样可以使系统变得更加安全，系统可移植性更高，也使代码变得更加容易阅读，如果一定要使用本地方法，请加强测试，并尽可能的少用。

NO.37 谨慎地进行优化
    努力写好的程序而不是快的程序，程序要体现信息隐藏的原则，，性能问题应该是设计阶段就考虑，要避免那些限制性能的设计决定，如：应该用复合模式的公有类使用继承，则该类的性能永久的受其父类性能的影响，为了获得好的性能而对 API进行修改并非是一个好的做法，通常，这些做法对性能并没什么多大的影响，如果一个系统有了清晰、简明、结构良好的实现，请谨慎对其进行优化，因为 80%的性能问题存在于 20%的代码中，找出影响性能的代码才是问题的关键，可以借助一些性能分析的工具。