[代码优化]null校验的优美处理

我们写java代码的时候，使用对象前，都会下意识先判断对象非null，这是防止NPE的无奈之举，毕竟入门写代码时都写过npe的代码。这么做真的好吗，每层方法中都有这null的判断，导致很多null的判断都是重复的，我们对每个方法的返回都持有一个怀疑不确定的态度，是导致代码各个地方都有非null校验的原因。

在严格的面向接口编程的语义中，通过接口方法我们就应该了解返回的是否会存在没有数据的情况，只有接口提示存在没有结果返回时，代码才会有非null的校验逻辑。在开发过程中大部分方法，是没有体现返回是否可能为null的语义的。

// 这种方法无法体现返回是否可能为null的语义
T get(Integer id);

在java8中，提供了Optional类来包装对象，用这个Optional包装对象，我们可以体现返回是否可能为null的语义，从而解决代码中无处不在的null检查。我们可以这样规定，如果方法返回的是对象，那么它的返回一定不为null；如果方法返回的是Optional对象，则表示方法返回结果可能存在null，需要做非null处理。

T get()返回不为null的实践一般是当接口为null时，抛出异常，这样就做到返回一定不为null了。

// 这种方法代表返回结果一定不为null，调用这个方法不用做null处理
T get(Integer id);

// 这种方法代表返回结果可能
Optional<T> get(Integer id);

对于返回可能存在null的方法，Optional对象也提供了一些优雅的处理方式。我之前使用Optional.isPresent来判断是否有值后再进行