Java开发的一些编码建议
1、无论是类、方法、字段、变量，尽可能的限制他们的作用范围，可以避免出现不必要的错误；同时虚拟机也能有更大的优化空间。
2、错误越早发现越好，编译时发生错误比在运行时发生错误好。而且编译时错误能更好的定位问题所在。
这两条建议来源于阅读《Effective Java》后的总结。
书中第15条：使类和成员的可访问性最小化以及第16条：要在公有类中使用访问方法而非公有域大部分使用Spring开发的人都会这么去做，但是我觉得大部分的初级开发甚至是中级开发者并不知道为什么要这么做，只不过是在依葫芦画瓢。
一个设计良好的类除了要满足高内聚、低耦合之外应当还要具备良好的封装性。以常用的ArrayList举例，在idea中进行编码时输入"list."之后idea就会列出add、set等方法，但是不会出现grow等实现细节所需的方法，即使自己拼出来方法名也无法通过编译。
试想一下，倘若一个类只提供两个客户端所需要的方法，然后有很多实现细节所需的方法，但是这些方法并没有封装。后果就是不熟悉这个类的人需要去看所有方法的注释或者源码，这对使用该类的开发人员是一种极其不好的体验，而且还可能因为疏忽调用错方法导致程序没有按照开发者所预想的逻辑进行，但是这个错误无法在编译时发现，如果测试用例正好没覆盖到此处，那么这个错误可能在某一天对系统产生重大的影响。开发者所能做的就是尽可能的把错误扼杀在摇篮。
至于第十六条估计没有Java开发者不遵守，在编写实体类时字段都为private，然后通过getter、setter方法去获取与修改。初学Java时觉得这种做法跟脱裤子放屁一样多此一举。
现在才明白字段field权限为public那将意味着这个类失去了对该字段的控制。试想如果field为int类型，但是类的设计者希望field的大小只在1-10之间，那设计者只能在每次使用field时进行校验（因为要把使用者当傻子，不能指望他能按照预期进行输入），如果field是在多处使用，代码看上去很臃肿，并且容易在某个地方遗漏，特别是其他开发者进行维护时。field权限为private就没这么多事了，因为在setter时可以直接校验。
第40条：坚持使用Override注解
@Override注解都知道是覆盖超类方法用的，但是不加其实也能覆盖，程序不会出现任何问题，那么他的意义在哪呢？请看以下代码
public class Bigram {private final char first;private final char second;public Bigram(char first, char second){this.first = first;this.second = second;}public boolean equals(Bigram b){return b.first == first && b.second == second;}public int hashCode(){return 31 * first + second;}public static void main(String[] args) {Set<Bigram> s = new HashSet<>();for (int i = 0; i < 10; i++) {for (char ch = 'a'; ch <= 'z'; ch++) {s.add(new Bigram(ch,ch));}}System.out.println(s.size());}
}
代码意图很明显，往一个Set中添加a,a、b,b…z,z的实例对象，由于Set会去重，所以无论循环多少次按理说打印结果都是26，我阅读此处时也觉得是26，然而结果是260。
原因就是我们以为Bigram类覆盖了Object的equals，但其实是重载了，因为Object的equals方法形参是Object，而Bigram的形参是Bigram。
这种没有任何异常的逻辑错误，如果系统有一定的规模，排查的时候可以说是有不小难度的。如果在equals方法上加上@Override注解那么在编译时就能够提醒此处有问题，无法编译通过，能够很好的避免此类bug。
第49条：检查参数的有效性
很多方法或者构造器对于传递给它们的参数值都会有某些限制。最常见的限制有索引必须是非负数，对象引用不能为null等。这些限制应当在方法体开头处检查，尽早的发现错误。如果不对参数进行检查可能会发生以下三种情况：
1、抛出异常
2、方法正常返回，但是结果是错误的
3、破坏了某个对象的状态
如果是第一种情况其实还好，起码能通过堆栈信息发现错误。如果是第二或者第三种情况，在程序运行时是难以发现的，可能在某个时候对公司造成不可预估的损失。
假设有以下业务：系统统计班级捐款金额。
public class Donation {private int sum = 0;public void add(int money) {sum += money;}public int getSum() {return sum;}
}
当某个同学不小心输入了一个“-”，那么这样的bug是难以发现的，毕竟一两个人的捐款金额相对于一整个班级而言影响比较有限。
第57条：将局部变量的作用域最小化
最有力的例子就是for循环优于while循环
Iterator<Element> i = c.iterator;
while (i.hasNext()){doSomething(i.next());
}
....
Iterator<Element> i2 = c.iterator;
while (i.hasNext()){ //BUG，但是编译可以通过doSomething(i2.next());
}for (Iterator<Element> i = c.iterator;i.hasNext();){doSomething(i.next());
}
...
//编译无法通过，i的作用域只在上一个循环体中
for (Iterator<Element> i2 = c.iterator;i.hasNext();){doSomething(i2.next());
}
别说不会犯这种错误，复制粘贴多了总会有犯错的情况。（如果只是遍历读取的情况，for-each比for循环更合适，但是与本篇博客的两个总结点无关，所以没有写）
结语
为什么不按照《Effective Java》的排版进行总结？
因为有些内容还没理解透彻，再加上这些内容可能在实际开发中更常用，这些内容的思想非常值得学习。还有一个原因就是在阅读《深入理解Java虚拟机》时学习了逃逸分析的相关内容，如果某个变量所引用的对象作用范围仅在当前方法，可能JVM会对其进行优化，该对象实例的内存不一定在堆中，可能是栈上分配，然后随着方法执行结束回收内存，能够有效的降低垃圾回收的运行，提高系统的性能。
可能《Effective Java》中还有其他条目也是这两种思想。但是阅读时间线比较长，以及有些部分还没阅读，可能会遗漏某些条目，发现了再补上。