Java8实战-重构、测试和调试（一）：https://developer.aliyun.com/article/1535501
责任链模式
责任链模式是一种创建处理对象序列（比如操作序列）的通用方案。一个处理对象可能需要在完成一些工作之后，将结果传递给另一个对象，这个对象接着做一些工作，再转交给下一个处理对象，以此类推。
通常，这种模式是通过定义一个代表处理对象的抽象类来实现的，在抽象类中会定义一个字段来记录后续对象。一旦对象完成它的工作，处理对象就会将它的工作转交给它的后继。代码中，这段逻辑看起来是下面这样：
private static abstract class AbstractProcessingObject<T> { protected AbstractProcessingObject<T> successor; public void setSuccessor(AbstractProcessingObject<T> successor) { this.successor = successor; } public T handle(T input) { T r = handleWork(input); if (successor != null) { return successor.handle(r); } return r; } protected abstract T handleWork(T input); } 复制代码
下面让我们看看如何使用该设计模式。你可以创建两个处理对象，它们的功能是进行一些文本处理工作。
private static class HeaderTextProcessing extends AbstractProcessingObject<String> { @Override protected String handleWork(String text) { return "From Raoul, Mario and Alan: " + text; } } private static class SpellCheckerProcessing extends AbstractProcessingObject<String> { @Override protected String handleWork(String text) { return text.replaceAll("labda", "lambda"); } } 复制代码
现在你就可以将这两个处理对象结合起来，构造一个操作序列！
AbstractProcessingObject<String> p1 = new HeaderTextProcessing(); AbstractProcessingObject<String> p2 = new SpellCheckerProcessing(); p1.setSuccessor(p2); String result = p1.handle("Aren't labdas really sexy?!!"); System.out.println(result); 复制代码
使用Lambda表达式稍等！这个模式看起来像是在链接（也即是构造） 函数。第3章中我们探讨过如何构造Lambda表达式。你可以将处理对象作为函数的一个实例，或者更确切地说作为 UnaryOperator 的一个实例。为了链接这些函数，你需要使用 andThen 方法对其进行构造。
UnaryOperator<String> headerProcessing = (String text) -> "From Raoul, Mario and Alan: " + text; UnaryOperator<String> spellCheckerProcessing = (String text) -> text.replaceAll("labda", "lambda"); Function<String, String> pipeline = headerProcessing.andThen(spellCheckerProcessing); String result2 = pipeline.apply("Aren't labdas really sexy?!!"); System.out.println(result2); 复制代码
工厂模式
使用工厂模式，你无需向客户暴露实例化的逻辑就能完成对象的创建。比如，我们假定你为一家银行工作，他们需要一种方式创建不同的金融产品：贷款、期权、股票，等等。
通常，你会创建一个工厂类，它包含一个负责实现不同对象的方法，如下所示：
private interface Product { } private static class ProductFactory { public static Product createProduct(String name) { switch (name) { case "loan": return new Loan(); case "stock": return new Stock(); case "bond": return new Bond(); default: throw new RuntimeException("No such product " + name); } } } static private class Loan implements Product { } static private class Stock implements Product { } static private class Bond implements Product { } 复制代码
这里贷款（ Loan ）、股票（ Stock ）和债券（ Bond ）都是产品（ Product ）的子类。createProduct 方法可以通过附加的逻辑来设置每个创建的产品。但是带来的好处也显而易见，你在创建对象时不用再担心会将构造函数或者配置暴露给客户，这使得客户创建产品时更加简单：
Product p1 = ProductFactory.createProduct("loan"); 复制代码
使用Lambda表达式第3章中，我们已经知道可以像引用方法一样引用构造函数。比如，下面就是一个引用贷款（ Loan ）构造函数的示例：
Supplier<Product> loanSupplier = Loan::new; Product p2 = loanSupplier.get(); 复制代码
通过这种方式，你可以重构之前的代码，创建一个 Map ，将产品名映射到对应的构造函数：
final static private Map<String, Supplier<Product>> map = new HashMap<>(); static { map.put("loan", Loan::new); map.put("stock", Stock::new); map.put("bond", Bond::new); } 复制代码
现在，你可以像之前使用工厂设计模式那样，利用这个 Map 来实例化不同的产品。
public static Product createProductLambda(String name) { Supplier<Product> p = map.get(name); if (p != null) { return p.get(); } throw new RuntimeException("No such product " + name); } 复制代码
这是个全新的尝试，它使用Java 8中的新特性达到了传统工厂模式同样的效果。但是，如果工厂方法 createProduct 需要接收多个传递给产品构造方法的参数，这种方式的扩展性不是很好。你不得不提供不同的函数接口，无法采用之前统一使用一个简单接口的方式。
比如，我们假设你希望保存具有三个参数（两个参数为 Integer 类型，一个参数为 String类型）的构造函数；为了完成这个任务，你需要创建一个特殊的函数接口 TriFunction 。最终的结果是 Map 变得更加复杂。
public interface TriFunction<T, U, V, R>{ R apply(T t, U u, V v); } Map<String, TriFunction<Integer, Integer, String, Product>> map = new HashMap<>(); 复制代码
你已经了解了如何使用Lambda表达式编写和重构代码。接下来，我们会介绍如何确保新编 写代码的正确性。
测试 Lambda 表达式
现在你的代码中已经充溢着Lambda表达式，看起来不错，也很简洁。但是，大多数时候，我们受雇进行的程序开发工作的要求并不是编写优美的代码，而是编写正确的代码。
通常而言，好的软件工程实践一定少不了单元测试，借此保证程序的行为与预期一致。你编写测试用例，通过这些测试用例确保你代码中的每个组成部分都实现预期的结果。比如，图形应用的一个简单的 Point 类，可以定义如下：
public class Point { private final int x; private final int y; public Point(int x, int y) { this.x = x; this.y = y; } public int getX() { return x; } public int getY() { return y; } public Point moveRightBy(int x) { return new Point(this.x + x, this.y); } } 复制代码
下面的单元测试会检查 moveRightBy 方法的行为是否与预期一致：
public class PointTest { @Test public void testMoveRightBy() { Point p1 = new Point(5, 5); Point p2 = p1.moveRightBy(10); Assert.assertEquals(15, p2.getX()); Assert.assertEquals(5, p2.getY()); } } 复制代码
测试可见 Lambda 函数的行为
由于 moveRightBy 方法声明为public，测试工作变得相对容易。你可以在用例内部完成测试。但是Lambda并无函数名（毕竟它们都是匿名函数），因此要对你代码中的Lambda函数进行测试实际上比较困难，因为你无法通过函数名的方式调用它们。
有些时候，你可以借助某个字段访问Lambda函数，这种情况，你可以利用这些字段，通过它们对封装在Lambda函数内的逻辑进行测试。比如，我们假设你在 Point 类中添加了静态字段compareByXAndThenY ，通过该字段，使用方法引用你可以访问 Comparator 对象：
public class Point { public final static Comparator<Point> COMPARE_BY_X_AND_THEN_Y = comparing(Point::getX).thenComparing(Point::getY); ... } 复制代码
还记得吗，Lambda表达式会生成函数接口的一个实例。由此，你可以测试该实例的行为。这个例子中，我们可以使用不同的参数，对 Comparator 对象类型实例 compareByXAndThenY的 compare 方法进行调用，验证它们的行为是否符合预期：
@Test public void testComparingTwoPoints() { Point p1 = new Point(10, 15); Point p2 = new Point(10, 20); int result = Point.COMPARE_BY_X_AND_THEN_Y.compare(p1 , p2); Assert.assertEquals(-1, result); } 复制代码
测试使用 Lambda 的方法的行为
但是Lambda的初衷是将一部分逻辑封装起来给另一个方法使用。从这个角度出发，你不应该将Lambda表达式声明为public，它们仅是具体的实现细节。相反，我们需要对使用Lambda表达式的方法进行测试。比如下面这个方法 moveAllPointsRightBy ：
public static List<Point> moveAllPointsRightBy(List<Point> points, int x) { return points.stream() .map(p -> new Point(p.getX() + x, p.getY())) .collect(toList()); } 复制代码
我们没必要对Lambda表达式 p -> new Point(p.getX() + x,p.getY()) 进行测试，它只是 moveAllPointsRightBy 内部的实现细节。我们更应该关注的是方法 moveAllPointsRightBy 的行为：
@Test public void testMoveAllPointsRightBy() { List<Point> points = Arrays.asList(new Point(5, 5), new Point(10, 5)); List<Point> expectedPoints = Arrays.asList(new Point(15, 5), new Point(20, 5)); List<Point> newPoints = Point.moveAllPointsRightBy(points, 10); Assert.assertEquals(expectedPoints, newPoints); } 复制代码
注意，上面的单元测试中， Point 类恰当地实现 equals 方法非常重要，否则该测试的结果就取决于 Object 类的默认实现。
调试
调试有问题的代码时，程序员的兵器库里有两大老式武器，分别是：
- 查看栈跟踪
- 输出日志
查看栈跟踪
你的程序突然停止运行（比如突然抛出一个异常），这时你首先要调查程序在什么地方发生了异常以及为什么会发生该异常。这时栈帧就非常有用。程序的每次方法调用都会产生相应的调用信息，包括程序中方法调用的位置、该方法调用使用的参数、被调用方法的本地变量。这些信息被保存在栈帧上。
程序失败时，你会得到它的栈跟踪，通过一个又一个栈帧，你可以了解程序失败时的概略信息。换句话说，通过这些你能得到程序失败时的方法调用列表。这些方法调用列表最终会帮助你发现问题出现的原因。
Lambda表达式和栈跟踪不幸的是，由于Lambda表达式没有名字，它的栈跟踪可能很难分析。在下面这段简单的代码中，我们刻意地引入了一些错误：
public class Debugging { public static void main(String[] args) { List<Point> points = Arrays.asList(new Point(12, 2), null); points.stream().map(p -> p.getX()).forEach(System.out::println); } } 复制代码
运行这段代码会产生下面的栈跟踪：
12 Exception in thread "main" java.lang.NullPointerException // 这行中的 $0 是什么意思？ at xin.codedream.java8.chap8.Debugging.lambda$main$0(Debugging.java:15) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) ... 复制代码
这个程序出现了NPE（空指针异常）异常，因为 Points 列表的第二个元素是空（ null ）。
这时你的程序实际是在试图处理一个空引用。由于Stream流水线发生了错误，构成Stream流水线的整个方法调用序列都暴露在你面前了。不过，你留意到了吗？栈跟踪中还包含下面这样类似加密的内容：
at xin.codedream.java8.chap8.Debugging.lambda$main$0(Debugging.java:15) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 复制代码
这些表示错误发生在Lambda表达式内部。由于Lambda表达式没有名字，所以编译器只能为它们指定一个名字。这个例子中，它的名字是 lambda
mainmain0 ，看起来非常不直观。如果你使用了大量的类，其中又包含多个Lambda表达式，这就成了一个非常头痛的问题。
即使你使用了方法引用，还是有可能出现栈无法显示你使用的方法名的情况。将之前的Lambda表达式 p-> p.getX() 替换为方法引用 reference Point::getX 也会产生难于分析的栈跟踪：
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) 复制代码
注意，如果方法引用指向的是同一个类中声明的方法，那么它的名称是可以在栈跟踪中显示的。比如，下面这个例子：
public class Debugging { public static void main(String[] args) { List<Integer> numbers = Arrays.asList(1, 2, 3); numbers.stream().map(Debugging::divideByZero).forEach(System .out::println); } public static int divideByZero(int n) { return n / 0; } } 复制代码
方法 divideByZero 在栈跟踪中就正确地显示了：
Exception in thread "main" java.lang.ArithmeticException: / by zero // divideByZero正确地输出到栈跟踪中 at xin.codedream.java8.chap8.Debugging.divideByZero(Debugging.java:20) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ... 复制代码
总的来说，我们需要特别注意，涉及Lambda表达式的栈跟踪可能非常难理解。这是Java编译器未来版本可以改进的一个方面。
使用日志调试
假设你试图对流操作中的流水线进行调试，该从何入手呢？你可以像下面的例子那样，使用forEach 将流操作的结果日志输出到屏幕上或者记录到日志文件中：
List<Integer> numbers = Arrays.asList(2, 3, 4, 5); numbers.stream() .map(x -> x + 17) .filter(x -> x % 2 == 0) .limit(3) .forEach(System.out::println); 复制代码
这段代码的输出如下：
20 22 复制代码
不幸的是，一旦调用 forEach ，整个流就会恢复运行。到底哪种方式能更有效地帮助我们理解Stream流水线中的每个操作（比如 map 、 filter 、 limit ）产生的输出？
这就是流操作方法 peek 大显身手的时候。 peek 的设计初衷就是在流的每个元素恢复运行之前，插入执行一个动作。但是它不像 forEach 那样恢复整个流的运行，而是在一个元素上完操作之后，它只会将操作顺承到流水线中的下一个操作。下面的这段代码中，我们使用 peek 输出了Stream流水线操作之前和操作之后的中间值：
List<Integer> result = Stream.of(2, 3, 4, 5) .peek(x -> System.out.println("taking from stream: " + x)).map(x -> x + 17) .peek(x -> System.out.println("after map: " + x)).filter(x -> x % 2 == 0) .peek(x -> System.out.println("after filter: " + x)).limit(3) .peek(x -> System.out.println("after limit: " + x)).collect(toList()); 复制代码
通过 peek 操作我们能清楚地了解流水线操作中每一步的输出结果：
taking from stream: 2 after map: 19 taking from stream: 3 after map: 20 after filter: 20 after limit: 20 taking from stream: 4 after map: 21 taking from stream: 5 after map: 22 after filter: 22 after limit: 22 复制代码
小结
- Lambda表达式能提升代码的可读性和灵活性。
- 如果你的代码中使用了匿名类，尽量用Lambda表达式替换它们，但是要注意二者间语义的微妙差别，比如关键字 this ，以及变量隐藏。
- 跟Lambda表达式比起来，方法引用的可读性更好 。
- 尽量使用Stream API替换迭代式的集合处理。
- Lambda表达式有助于避免使用面向对象设计模式时容易出现的僵化的模板代码，典型的比如策略模式、模板方法、观察者模式、责任链模式，以及工厂模式。
- 即使采用了Lambda表达式，也同样可以进行单元测试，但是通常你应该关注使用了Lambda表达式的方法的行为。
- 尽量将复杂的Lambda表达式抽象到普通方法中。
- Lambda表达式会让栈跟踪的分析变得更为复杂。
- 流提供的 peek 方法在分析Stream流水线时，能将中间变量的值输出到日志中，是非常有用的工具。
