2.4.5 getter 与setter
在实例方法中有一类特殊的方法，即getter 与setter 方法，它们一般不包含任何业务逻辑，仅仅是为类成员属性提供读取和修改的方法，这样设计有两点好处：
（1）满足面向对象语言封装的特性。尽可能将类中的属性定义为private，针对属性值的访问与修改需要使用相应的getter 与setter 方法，而不是直接对public 的属性进行读取和修改。
（2）有利于统一控制。虽然直接对属性进行读取、修改的方式和使用相应的getter 与setter 方法在效果上是一样的，但是前者难以应对业务的变化。例如，业务要求对某个属性值的修改要增加统一的权限控制，如果有setter 作为统一的属性修改方法则更容易实现，这种情况在一些使用反射的框架中作用尤其明显。
因此，在类成员属性需要被外部访问的类中，getter 与setter 方法是必备的。除特殊情况需要增加业务逻辑外，它们仅仅是对成员属性的访问和修改操作，其承载的信息价值比较低，所以，建议在类定义中，类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。
最典型的getter 与setter 方法使用是在POJO（Plain Ordinary Java Object，简单的Java 对象）类中。在本书中，POJO 专指只包含getter、setter、toString 方法的简单类，常见的POJO 类包括DO（Dada Object）、 BO（Business Object）、DTO（Data Transfer Object）、VO（View Object）、AO（Application Object）。POJO 作为数据载体，通常用于数据传输，不应该包含任何业务逻辑。因此，在POJO 类中，getter 与setter不但是重要的组成部分，更是与外界进行信息交换的桥梁。getter 与setter 方法定义参考示例如下：
public class TicketDO {
private Long id;
// 目的地
private String destination;
// getter 方法，要求：直接返回相应属性值，不增加业务逻辑
public Long getId() {
return id;
}
public String getDestination() {
return destination;
}
// 参数名称与类成员变量名称一致，定义中this. 成员名= 参数名，尽量不增加业务逻辑
public void setId(Long id) {
this.id = id;
}
public void setDestination(String destination) {
this.destination = destination;
}
}
getter 与setter 方法的定义非常简单，正因如此，工程师们会放松对它们的警惕，导致在实际应用中因为不当操作出现问题。下面来罗列那些易出错的getter 与setter方法定义方式：
（1） getter/setter 中添加业务逻辑。问题出现时，程序员的惯性思维会忽略getter/setter 方法的嫌疑，这会增加排查问题的难度。如下示例代码，在getData() 中增加了逻辑判断，修改了原属性值，如出现属性值不一致的情况，这里可能会是程序员最后被排查到的地方。
public Integer getData() {
if (condition) {
return this.data + 100;
} else {
return this.data - 100;
}
}
（2）同时定义isXxx() 和getXxx()。在类定义中，两者同时存在会在iBATIS、JSON 序列化等场景下引起冲突。比如，iBATIS 通过反射机制解析加载属性的getter方法时，首先会获取对象所有的方法，然后筛选出以get 和is 开头的方法，并存储到类型为HashMap 的getMethods 变量中。其中key 为属性名称，value 为getter 方法。因此isXxx() 和getXxx() 方法只能保留一个，哪个方法被后存储到getMethods 变量中，就会保留哪个方法，具有一定的随机性。所以当两者定义不同时，会导致误用，进而产生问题。
与此相关的某个故障中，负责故障回顾的同事在内网发了一篇贴子，标题为“珍爱生命，远离有毒getter”，即在某个POJO 类中，Boolean 属性既有getXxx()，又有isXxx()。isXxx() 的逻辑存在错误，在修复故障时，想当然地在getXxx() 方法中进行修正，但无法修复故障，因为事实上调用的是isXxx()。排查了完整的调用链路，问题才回到POJO 类本身上。这个过程花费了大量的排查精力和故障处理的宝贵时间。
（3）相同的属性名容易带来歧义。在编程过程中，应该尽量避免在子父类的成员变量之间、不同代码块的局部变量之间采用完全相同的命名。虽然这样定义是合法的，但是要避免。这样使用非常容易引起混淆，在使用参数时，难以明确属性的作用域，最终难以分清到底是父类的属性还是子类的属性。扩展开来，对于非setter/getter的参数名称也要避免与成员变量名称相同。
public class ConfusingName {
public int alibaba;
// 反例：非setter/getter 方法的参数名称，不允许与本类成员变量同名
public void get(String alibaba) {
if(true) {
final int taobao = 15;
...
}
for (int i = 0; i < 10; i++) {
// 在同一方法体中，不允许与其他代码块中的taobao 命名相同
final int taobao = 15;
...
}
}
}
class Son extends ConfusingName {
// 反例：不允许与父类的成员变量名称相同
public int alibaba;
}
2.4.6 同步与异步
同步调用是刚性调用，是阻塞式操作，必须等待调用方法体执行结束。而异步调用是柔性调用，是非阻塞式操作，在执行过程中，如调用其他方法，自己可以继续执行而不被阻塞等待方法调用完毕。异步调用通常用在某些耗时长的操作上，这个耗时方法的返回结果，可以使用某种机制反向通知，或者再启动一个线程轮询。反向通知方式需要异步系统和各个调用它的系统进行耦合；而轮询对于没有执行完的任务会不断地请求，从而加大执行机器的压力。
异步处理的任务是非时间敏感的。比如，在连接池中，异步任务会定期回收空闲线程。举个现实中的例子，在代码管理平台中，提交代码的操作是同步调用，需要实时返回给用户结果。但是当前库的代码相关活动记录不是时间敏感的，在提交代码时，发送一个消息到后台的缓存队列中，后台服务器定时消费这些消息即可。
某些框架提供了丰富的异步处理方式，或者是把同步任务拆解成多个异步任务等。
