1.设计模式

1.1.对设计经验的归纳总结

1.2.一种可重用的蓝图

1.3.Java 5引入了for-each循环

1.3.1.替代了很多显式使用迭代器的情形

1.4.Java 7推出的菱形操作符（<>）

1.4.1.帮助大家在创建实例时无须显式使用泛型

1.4.2.推动了Java程序员们采用类型接口（type interface）进行程序设计

1.5.单例模式

1.5.1.一般用于限制类的实例化，仅生成一份对象

1.6.访问者模式

1.6.1.常用于分离程序的算法和它的操作对象

2.策略模式

2.1.解决一类算法的通用解决方案，你可以在运行时选择使用哪种方案

2.2.一个代表某个算法的接口（Strategy接口）

2.3.一个或多个该接口的具体实现，它们代表了算法的多种实现

2.4.一个或多个使用策略对象的客户

2.5.Lambda表达式避免了采用策略设计模式时僵化的模板代码

3.模板方法模式

3.1.如果需要采用某个算法的框架，同时又希望有一定的灵活度，能对它的某些部分进行改进

3.2.“希望使用这个算法，但是需要对其中的某些行进行改进，才能达到希望的效果”时是非常有用的

3.3.通过传递Lambda表达式，直接插入不同的行为，不再需要继承

3.4.Lamba表达式能帮助解决设计模式与生俱来的设计僵化问题

4.观察者模式

4.1.消除僵化代码

4.1.1.直接传递Lambda表达式表示需要执行的行为即可

4.2.某些事件发生时（比如状态转变），如果一个对象（通常称之为主题）需要自动地通知其他多个对象（称为观察者）

5.责任链模式

5.1.通过定义一个代表处理对象的抽象类来实现的，在抽象类中会定义一个字段来记录后续对象

5.2.UnaryOperator的一个实例

5.2.1.为了链接这些函数，需要使用andThen方法对其进行构造

6.工厂模式

6.1.无须向客户暴露实例化的逻辑就能完成对象的创建

6.2.特殊的函数接口TriFunction

          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<>();

7.改善程序代码的可读性

7.1.代码的可读性

7.1.1.别人理解这段代码的难易程度

7.1.2.确保你的代码能非常容易地被包括自己在内的所有人理解和维护

7.2.重构代码，用Lambda表达式取代匿名类

7.3.用方法引用重构Lambda表达式

7.4.用Stream API重构命令式的数据处理

8.从匿名类到Lambda表达式的转换

8.1.“更简洁”来描述Lambda表达式是因为相较于匿名类

8.2.匿名类和Lambda表达式中的this和super的含义是不同的

8.2.1.在匿名类中，this代表的是类自身

8.2.2.在Lambda中，它代表的是包含类

8.3.匿名类可以屏蔽包含类的变量

8.4.Lambda表达式不能（会导致编译错误）

8.5.涉及重载的上下文里，将匿名类转换为Lambda表达式可能导致最终的代码更加晦涩

8.5.1.匿名类的类型是在初始化时确定的

8.5.2.Lambda的类型取决于它的上下文

8.5.3.Task尝试使用显式的类型转换来解决这种模棱两可的情况

8.5.4.NetBeans、Eclipse和IntelliJ都支持这种重构，能自动地帮你检查，避免发生这些问题

9.从Lambda表达式到方法引用的转换

9.1.Lambda表达式非常适用于需要传递代码片段的场景

9.2.尽量将复杂的Lambda表达式抽象到普通方法中

9.3.为了改善代码的可读性，请尽量使用方法引用

9.3.1.利用这种方法能写出非常简洁的代码

9.4.尽量考虑使用静态辅助方法

9.4.1.比如comparing和maxBy

9.4.2.这些方法设计之初就考虑了会结合方法引用一起使用

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

10.1.Stream API能更清晰地表达数据处理管道的意图

10.2.建议将所有使用迭代器这种数据处理模式处理集合的代码都转换成Stream API的方式

10.3.通过短路和延迟载入以及计算机的多核架构，可以对Stream进行优化

10.3.1.LambdaFicator

11.增加代码的灵活性

11.1.采用函数接口

11.1.1.没有函数接口，就无法使用Lambda表达式

11.2.有条件的延迟执行

11.2.1.控制语句被混杂在业务逻辑代码之中

11.2.2.频繁地从客户端代码去查询一个对象的状态，只是为了传递参数、调用该对象的一个方法，那么可以考虑实现一个新的方法，以Lambda或者方法引用作为参数，新方法在检查完该对象的状态之后才调用原来的方法

11.2.3.代码会因此而变得更易读（结构更清晰），封装性更好（对象的状态也不会暴露给客户端代码了）

11.3.环绕执行

11.3.1.拥有同样的准备和清理阶段

12.测试Lambda表达式

12.1.测试可见Lambda函数的行为

12.2.测试使用Lambda的方法的行为

12.2.1.Lambda的初衷是将一部分逻辑封装起来给另一个方法使用

12.2.2.不应该将Lambda表达式声明为public，它们仅是具体的实现细节

12.3.将复杂的Lambda表达式分为不同的方法

12.3.1.将Lambda表达式转换为方法引用

12.3.2.需要声明一个新的常规方法

12.3.3.用常规的方式对新的方法进行测试

12.4.高阶函数的测试

12.4.1.如果一个方法接受Lambda表达式作为参数，那么你可以采用的一个方案是使用不同的Lambda表达式对它进行测试

13.调试

13.1.查看栈跟踪

13.1.1.由于Lambda表达式没有名字，因此它的栈跟踪可能很难分析

13.2.使用日志调试

13.2.1.流操作方法peek

13.2.2.peek的设计初衷就是在流的每个元素恢复运行之前，插入执行一个动作