EffectiveJava——通用程序设计

第45条：将局部变量的作用域最小化

将局部变量的作用域最小化可增强代码的可读性，可维护性，并降低出错的可能性。最有效的方法就是：在第一次使用它的地方声明。

1

如果在循环之后不在需要循环变量的内容，for循环就要优先于while循环。以防止发生剪切，粘贴错误。

下面是一种对局部变量的作用域最小化的循环做法：

for(int i =0 , n = expensiveComputation() ; i < n ; i ++){
                doSomething(i);                                 
}

这时，i和n具有完全相同的作用域

2

将局部变量作用域最小化的方法是使方法小而集中如果执行一个操作的局部变量可能出现在同一个方法的另一操作中，就可以考虑拆分方法。

第46条：for-each循环优先于传统的for循环

利用for-each不会有任何的性能损失，甚至稍有优势。
fro-each不仅可以遍历集合和数组，还可以遍历任何实现了Iterable接口的对象

public interface Iterable<T> {

    Iterator<T> iterator();

}

实现Iterable并不难。

有三种情况不适合for-each循环：
- 过滤，可能需要remove
- 转换
- 平行迭代

第47条：了解和使用类库

不要重复的发明轮子！，某些功能需求，可能在API中已经实现，只是你没有发现而已。

每个程序员都应该熟悉java.lang, java.util,某种程度上还要属性java.io中的内容！！！
对于并发相关，你应该属性java.util.concurrent的高级部分。

第48条：如果需要精确的答案，请避免使用float和double

float和double用于科学计数和工厂计算，他们执行二进制否点运算，它们并没有提供完全精确的计算结果，float和doubel尤其不适合用于货币计算。
如果需要精确的答案，请使用BitDecemal

第49条：基本类型优先于装箱类型

基本类型与装箱类型区别：
- 基本类型只有值，而装箱类型具有与他们值不同的统一性。即两个装箱基本类型可以具有相同的值和不同的同一性
- 基本类型只具有功能完备的值，每个装箱类型处理完备的值，还具有非功能值:null
- 基本类型比装箱类型更节约时间和空间

总是，自动装箱减少了使用装箱类型的繁琐性，但是并没有减少它的风险。

第50条：如果其他类型更适合，则尽量避免使用字符串

• 字符串不适合代替其他类型值。
• 字符串不适合代替枚举类型
  参见第30条
• 字符串不适合代替聚焦类型
• 字符串不适合代替能力表

第51条：当心字符串的连接性能

为连接n个字符串而重复的使用字符串连接操作符，需要n的平方级时间。两个字符串被连接在一起时，他们的内容都要被拷贝。

考虑使用StringBuilder代替String的连接。

第52条：通过接口引用对象

如果有合适的接口类型存在，那么对于参数，返回值，变量和域来说，都应该使用接口类型进行声明。

如果你养成接口作为类型的习惯，你的程序将更加的灵活。

接口类型可以被方便的替换具体实现：
有一点值得注意：如果原来的实现提供了某种特殊的功能，而这种功能并不是接口的通用约定，并且周围的代码又依赖于这种功能，那么很关键的一点，新的实现也应该提供同样的功能，对于这种功能需要添加注释。

第53条：接口优先于反射机制

核心反射机制提供了通过程序来访问关于已装载的类的信息的能力，但是这种能力也要付出代价：
- 丧失了编译时类型检查的好处
- 执行反射所需要的代码非常笨重与冗长
- 性能损失

如果只是以非常有限的形式使用反射机制，虽然也要付出少许代价，但是可以获得许多好处，对于某些程序，他们必须用到在编译时无法获取的类，但是在编译时存在适当的接口或者超类，通过他们可以引用这个类，如果是这种情况，就可以以反射方式创建实例，然后通过他们的接口或者操作，以正常的方式访问这些实例。

第54条：谨慎的使用本地方法

本地语言是不安全的。也不是跨平台的。使用时需要仔细考虑

第55条：谨慎的进行优化

对于优化有以下格言：

• 很多计算上的过失都被归咎于效率(没有必要达到的效率)，而不是任何其他原因——甚至包括盲目的做傻事
• 不要去计较效率上的一些小小的得失，在97%的情况下，不成熟的优化才是一切问题的根源。
• …

不要因为性能而牺牲合理的结构，要努力编写好的程序而不是快的程序。如果好处程序不够快，他的结构将使他可以得到优化。好的程序体现了信息隐藏的原则，只要有可能，他们就会把设计决策集中在单个模块中。因此改变单个决策，而不影响全局

要考虑API设计决策的性能后果：
- 使公共类型成为可变的，这可能会导致大量不必要的保护性拷贝
- 在适合使用复合模式的共有类中使用继承，会导致这个类与它的超类永远舒服在一起。
- 在API中使用实现类类型，而不是接口类型。会把你束缚在一个具体的实现上。

第56条：遵守普遍接受的命名规则

略