高质量编码系列均是出自《编写高质量代码：改善Java程序的151个建议》一书。算是自己看完以后做的一个小结。
关于equals方法是我们经常使用的一个方法，相信很多朋友在面试复习的时候也常常碰到类似的知识点，如自定义的对象须要重写equals和hashcode方法...下面我也将提到这几点。
覆写equals方法不要识别不出自己
这一点我们在日常开发中可能会疏忽。
现在我们来看一个例子，我们手头有个person类，需要通过他们的名字来判断两者是否相等，因为Object类默认equals是通过地址来判断的。
我们重写了Person的equals方法，如下
@Override
public boolean equals(Object obj){
if(obj != null && obj.instanceof Person){
Person person = (Person)obj;
if(person.getName() != null && this.name != null){
return name.equalsIgnoreCase(p.getName.trim());
}
return false;
}
}
我们用重写后的类来看下面的例子
Person p1 = new Person("老张");
Person p2 = new Person("老李 ");
List<Person> list = new ArrayList();
list.add(p1);
list.add(p2);
System.out.println(list.contains(p1));
System.out.println(list.contains(p2));
大家猜猜看结果是什么呢？
true
false
相信有点兄嘚已经发现了，重写后的equals代码有一个问题，即存在list里的串未经过trim处理，而我们判断相等的时候却对传的person.getName()进行了trim处理，这显然是不合适的
改进方法也很简单，我们把trim的处理放到person.getName()逻辑中。
即
public String getName(){
return name == null ? name : name.trim();
}
当然，这样的话，equals方法中也就不需要进行trim处理了，直接比较两者的名字即可。
equals应考虑null值情景
其实我们上面的处理已经将传入值为null的情况考虑进去了
NPE是我们开发中很常见的一种异常，大家在开发中需要时刻提醒自己进行空值校验。说来惭愧，我在初入职场的时候犯了一个很低级的错误，稍微侃一下，工作中开发是分环境进行的，一些常用的属性我们一般都是放在配置文件中的，而要命的是，我在测试环境中进行了配置，却疏忽了配置正式环境，导致这个值上了正式取不到了，而且我在编码中并未对取出的值进行空值校验...结果我就不说了...
反正大家以我为反面教材，不要像我一样憨憨的，相信大家不会犯少发配置这种低级错误，但在编码中多进行空值判断，因为NPE导致的线上问题还是有不少的...