8.1.1 改善代码的可读性
改善代码的可读性到底意味着什么?我们很难定义什么是好的可读性，因为这可能非常主观。通常的理解是，“别人理解这段代码的难易程度”。改善可读性意味着你要确保你的代码能非常容易地被包括自己在内的所有人理解和维护。为了确保你的代码能被其他人理解,有几个步骤可以尝试，比如确保你的代码附有良好的文档，并严格遵守编程规范。跟之前的版本相比较，Java8的新特性也可以帮助提升代码的可读性:
口使用Java8，你可以减少冗长的代码，让代码更易于理解口通过方法引用和StreamAPI，你的代码会变得更直观这里我们会介绍三种简单的重构，利用Lambda表达式、方法引用以及Stream改善程序代码的可读性:
口重构代码，用amnbda表达式取代匿名类
口用方法引用重构Lammbda表达式
口用StreamAPI重构命令式的数据处理

改善可读性和灵活性重构代码

8.1.4 从命令式的数据处理切换到 Stream

  我们建议你将所有使用迭代器这种数据处理模式处理集合的代码都转换成Stream API的方式。为什么呢?Stream API能更清晰地表达数据处理管道的意图。除此之外，通过短路和延迟载人以及利用第7章介绍的现代计算机的多核架构，我们可以对Streamn进行优化。
比如，下面的命令式代码使用了两种模式:筛选和抽取，这两种模式被混在了一起，这样的代码结构迫使程序员必须彻底搞清楚程序的每个细节才能理解代码的功能。此外，实现需要并行运行的程序所面对的困难也多得多(具体细节可以参考7.2节的分支/合并框架):

List<gtring> dishNames =new rrayList<>()ifor(Dish dish:menu){
if(dish.getCalories()>300){
dishNames.add(dish.getName());

替代方案使用Steam API，采用这种方式编写的代码读起来更像是问题陈述，并行化也非常容易:

menu.parallelStream()
filter(d ->d.getCalories)>300).map(Dish::getName)collectitoList())

不幸的是，将命令式的代码结构转换为Stream API的形式是个困难的任务，因为你需要考虑控制流语句，比如break、continue、return，并选择使用恰当的流操作。好消息是已经有一些工具可以帮助我们完成这个任务.

8.1.5 增加代码的灵活性
第2章和第3章中，我们曾经介绍过Lambda表达式有利于行为参数化。你可以使用不同的Lambda表示不同的行为，并将它们作为参数传递给函数去处理执行。这种方式可以帮助我们淡定从容地面对需求的变化。比如，我们可以用多种方式为Predicate创建筛选条件，或者使用Comparator对多种对象进行比较。现在，我们来看看哪些模式可以马上应用到你的代码中，让你享受Lammbda表达式带来的便利。
1 采用函数接口
首先，你必须意识到，没有函数接口，你就无法使用Lambda表达式。因此，你需要在代码中引人函数接口。听起来很合理,但是在什么情况下使用它们呢?这里我们介绍两种通用的模式你可以依照这两种模式重构代码，利用Lambda表达式带来的灵活性，它们分别是:有条件的延迟执行和环绕执行。除此之外，在下一节，我们还将介绍一些基于面向对象的设计模式，比如策略模式或者模板方法，这些在使用Lammbda表达式重写后会更简洁
2.有条件的延迟执行
我们经常看到这样的代码，控制语句被混杂在业务逻辑代码之中。典型的情况包括进行安全性检查以及日志输出。比如，下面的这段代码，它使用了Java语言内置的Logger类:

if (logger.isLoggable(Log.FINER)){
logger.finer("Problem:"+ generateDiagnostic()) 

这段代码有什么问题吗?其实问题不少。
口日志器的状态(它支持哪些日志等级)通过isLoggable方法暴露给了客户端代码。
口为什么要在每次输出一条日志之前都去查询日志器对象的状态?这只能搞砸你的代码。

更好的方案是使用1og方法，该方法在输出日志消息之前，会在内部检查日志对象是否已经设置为恰当的日志等级:

logger.log(Level.FINER,"Problem:"+ generateDiagnostic());

这种方式更好的原因是你不再需要在代码中插人那些条件判断,与此同时日志器的状态也不再被暴露出去。不过，这段代码依旧存在一个问题。目志消息的输出与否每次都需要判断，即伸你已经传递了参数，不开启日志。
这就是Lambda表达式可以施展拳脚的地方。你需要做的仅仅是延迟消息构造，如此一来日志就只会在某些特定的情况下才开启(以此为例，当日志器的级别设置为FINER时)。显然，Java8的API设计者们已经意识到这个问题，并由此引人了一个对1og方法的重载版本，这个版本的1og方法接受一个supplier作为参数。这个替代版本的1og方法的函数签名如下:
public void log(Level level,supplier<string> msgSupplier)
你可以通过下面的方式对它进行调用:
logger.1og(Level.FINER，()->"Problem:+ateiagnosti))
如果日志器的级别设置恰当，1og方法会在内部执行作为参数传递进来的Lambda表达式。这里介绍的Log方法的内部实现如下:

public void log(Level level,supplier<String> msgSupplier){if(logger.isLoggable(level)){1og(level，msgSupplier.get())

执行Lambda表达式
从这个故事里我们学到了什么呢?如果你发现你需要频繁地从客户端代码去查询一个对象的状态(比如前文例子中的日志器的状态)，只是为了传递参数、调用该对象的一个方法(比如输出一条日志)，那么可以考虑实现一个新的方法，以Lambda或者方法表达式作为参数，新方法在检查完该对象的状态之后才调用原来的方法。你的代码会因此而变得更易读(结构更清晰)封装性更好(对象的状态也不会暴露给客户端代码了)。
3.环绕执行
第3章中，我们介绍过另一种值得考虑的模式，那就是环绕执行。如果你发现虽然你的业务代码千差万别,但是它们拥有同样的准备和清理阶段,这时，你完全可以将这部分代码用Lambda实现。这种方式的好处是可以重用准备和清理阶段的逻辑，减少重复冗余的代码。下面这段代码你在第3章中已经看过，我们再回顾一次。它在打开和关闭文件时使用了同样的逻辑，但在处理

文件时可以使用不同的Lambda进行参数化:
 
传入一个Lambda表达式processFile((BufferedReader b)->b.readLine());String twoLines =
String oneine
传入另一个Lambda表达式

processFile((BufferedReader b)->b.readLine()+ b.readLine());
public static String processFile(BufferedReaderProcessor p) throwsIOException{
try (BufferedReader br = new BufferedReader (new FileReader ("java8inact ion/chap8/data.txt"))){return p.process(br);
}

将BufferedReaderprocessor作为return p.process(br):执行参数传入使用Lambda表达式的函数接口，该接口能够抛出一个IOException
public interface BufferedReaderProcessori4String process(BufferedReader b)throws IException;
这一优化是凭借函数式接口BufferedReaderProcessor达成的,通过这个接口，你可以传

使用Lambda表达式的函数接口，该接口能够抛出一个IOException
public interface BufferedReaderProcessor{String process(BufferedReader b)throws IOException;
这一优化是凭借函数式接口BufferedReaderProcessor达成的,通过这个接口，你可以传递各种La1mba表达式对BufferedReader对象进行处理。通过这一节，你已经了解了如何通过不同方式来改善代码的可读性和灵活性。接下来，你会了解Lammbada表达式如何避免常规面向对象设计中的僵化的模板代码。

Validator numericValidator = new Validator(new IsNumeric());
boolean bl =numericValidator.validate("aaaa");
Validator lowerCaseValidator = new Validator(new IsAllLowerCase());
boolean b2 =lowerCaseValidator.validate("bbbb");

返回true
使用Lambda表达式
到现在为止，你应该已经意识到validationstrategy是一个函数接口了(除此之外，它还与Preaicate<string>具有同样的函数描述)。这意味着我们不需要声明新的类来实现不同的策略，通过直接传递Lambda表达式就能达到同样的目的，并且还更简洁:

Validator numericvalidatornew Validator((String s)-> s.matches("[a-z]+"));
boolean bl=numericValidator.validate("aaaa");
Validator lowerCaseValidator =new Validator((string s)-> s.matches("\\d+"));
boolean b2 =lowerCaseValidator.validate("bbbb");

直接传递Lambda表达式
正如你看到的，Lambda表达式避免了采用策略设计模式时僵化的模板代码。如果你仔细分析一下个中缘由，可能会发现，Lambda表达式实际已经对部分代码(或策略)进行了封装，而这就是创建策略设计模式的初衷。因此，我们强烈建议对类似的问题，你应该尽量使用Lambda表达式来解决。