前言
这是Java Rules系列的第二篇, 继续介绍一些规则和技巧。
1. 多用组合少用继承
这个规则其实在很多书中都提到过，在《重构》这本书中也有一个章节详细描述了原因，总结下来主要就是因为子类依赖于超类中的特定功能，超类可能随着不断迭代，功能内容有所修改，但是子类是继承自超类的，如果超类的基础功能发生变化，那么子类在代码完全没有变化的情况下，可能功能也发生了变化，产生了变化传导效应，对于分析问题和代码阅读可能都会存在不好的影响。而且写过代码的同学应该都有感触，在阅读别人代码的时候，如果代码中存在太多的继承关系，那么阅读起来是非常累的，而且很容易漏掉一些关键代码，所以总结下来就是在不是必须用继承的时候尽量少用继承，用组合来实现功能复用，这样代码阅读起来会更加简单。
2. 基于接口编程
上一条说了少用继承，但是这里说的继承不是实现，不要理解错了，实现是一个类针对一个接口来说的，我们是推荐基于接口编程的。基于接口编程最大的好处就是调用方调用的都是接口，它不关心接口后面的具体实现，这样就做到了功能模块之间的松耦合，并且模块内部的接口实现可以随意方便的变化，只要新的实现能够涵盖所有的方法就可以了，这样调用方在调用的接口的时候完全感知不到接口已经变动。
3. 集合类一定不要使用原始类
我们在编码过程中经常会用到集合类，例如List、HashMap、Queue等，这些集合类java是允许直接定义、直接使用的，例如List list = new ArrayList();但是对于初始化出来的list，我们可以随便add对象进去，因为集合类默认的集合item为Object，那么我们在对集合进行增加减少，在代码层面编译可能不会报错，但是执行的时候从list取出对象使用的时候可能报运行时错误。
这就要求我们在定义集合类对象的时候，最好指定好泛型List<String> list = new ArrayList<String>();，这样在编译阶段误插的对象如果类型不对，就直接报错了，不会等到运行时可能发生的偶发错误。还有个好处就是从集合中删除元素时不需要再进行手工转换了，编译器会自动插入隐式的转换，并确保不会失败。
4. 优先考虑泛型
我们在日常开发过程中经常遇到一些看起来差不多的类，处理逻辑都是一样，只是针对的对象不同，这个时候我们就应该要考虑下能不能用泛型呢？在很多知名框架中都大面积使用泛型，jdk内部很多类都使用了泛型，spring框架中也大面积使用泛型。
有个比较简单的判断该类是否可以用泛型替代的办法，就是当你把类中所有的实体类都用共同的接口或者Object替换掉，是否可以正常运行，如果可以那么就表示这个类可以用泛型替代，不用重复写那么多功能雷同的类。
下面就是一个泛型的例子，你可以试着看下把其中的E全部换成Object是不是还是能够完美运行。泛型还有很多用法，这里介绍的例子是最简单的无限制泛型，如果对于泛型类有要求必须是实现哪个接口或者继承自哪个类的，那么可以用限定泛型<E extends Food>.
public class Stack<E> {
private E[] elements;
private int size;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
@SuppressWarnings("unchecked")
public Stack() {
elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(E e) {
ensureCapacity();
elements[size++] = e;
}
private void ensureCapacity() {
if (elements.length == size)
elements = Arrays.copyOf(elements, 2 * size + 1);
}
public E pop() {
if(size == 0)
throw new EmptyStackException();
E result = elements[--size];
elements[size] = null;
return result;
}
}