五、 丑陋的Lambda表达式
由于Lambda表达式比较简洁和自由，所以写出来的代码天马星空，很容易造成代码可阅读性、可维护性差的问题。下面，作者总结了一些丑陋的Lambda表达式，并给出一些整改解决方案。
1. 无法理解的Lambda表达式
请看下面的Lambda表达式，不仔细阅读Lambda表达式的代码，并不知道这段Lambda表达式是干啥的。
如果抽象出一个私有静态“isPrime”（是否质数）方法，这段代码将会变得更容易理解。
2. 无法复用的Lambda表达式
假设，在代码中存在大量的重复Lambda表达式，将是代码变得更加臃肿和庞大。
如果抽象出一个公共“PrimeHelper.isPrime”（ 是否质数）方法，这两段代码可以复用一个方法并变得更简洁。
3. 无法单测的Lambda表达式
如果Lambda表达式的执行对象被Mock，就会导致单元测试中的Lambda表达式无法被执行。因此，该Lambda表达式将无法被单元测试所覆盖。
如果抽象出一个私有“parseEmployee”（解析雇员）方法，可以利用下列方法进行单元测试：
注意：
如果抽象出私有静态方法，只需要把“Whitebox.invokeMethod”方法第一个参数改为“EmployeeService.class”即可。
4. 无法确定入参的Lambda表达式
Lambda表达式跟匿名内部类一样，可以无限制地获取方法中的final或准final局部变量。这就导致，如果不完全阅读Lambda表达式的代码，就无法知道——Lambda表达式除了声明的输入参数外，还把多少方法输入参数或局部变量作为输入参数。
如果抽象出一个“buildEmployee”（构建雇员）方法，将会明确这个Lambda表达式的输入参数。
5. 代码量大的Lambda表达式
在阿里巴巴的《Java开发手册》中有这样的规定：
【推荐】单个方法的总行数不超过80行。
如果一个Lambda表达式代码量过于庞大，不光会影响代码的阅读行，也将会影响本身方法的代码总行数。
如果抽象出一个“buildEmployee”（构建雇员）方法，将会大大降低本身方法的代码总行数。
6. 套娃一样的Lambda表达式
Lambda表达式套Lambda表达式，一层一层地嵌套下去，只会让代码变得难以阅读和维护。
如果每层Lambda表达式都抽象出一个方法，将会使代码变得更便于阅读和维护。
接下篇：https://developer.aliyun.com/article/1226755?groupCode=java
