OO makes code understandable by encapsulating moving parting, but FP makes code understandable by minimizing moving parts. －Michael Feathers
Conditional Deferred Execution
日志Logger
if (logger.isLoggable(Level.INFO)) {
logger.info("problem:" + getDiagnostic());
}
这个实现存在如下一些坏味道：
- 重复的样板代码，并且散乱到用户的各个角落；
- 在
logger.debug之前，首先要logger.isLoggable，logger暴露了太多的状态逻辑，违反了LoD(Law of Demeter)
Eliminate Effects Between Unrelated Things.
Apply LoD
logger.info("problem:" + getDiagnostic());
这样的设计虽然将状态的查询进行了封装，但依然存在一个严重的性能问题。无论如何，getDiagnostic都将得到调用，如果它是一个耗时、昂贵的操作，将严重地影响了系统的性能。
Apply Lambda
灵活地应用Lambda惰性求值的特性，可以很漂亮地解决这个问题。
public void log(Level level, Supplier<String> supplier) {
if (isLoggable(level)) {
log(supplier.get());
}
}
public void debug(Supplier<String> supplier) {
log(Level.DEBUG, supplier);
}
public void info(Supplier<String> supplier) {
log(Level.INFO, supplier);
}
...
用户的代码也更加简洁，省略了那些重复的样板代码。
logger.info(() -> "problem:" + getDiagnostic());
Apply Scala: Call by Name
在使用lambda时多余的()显得有点冗余，可以使用by-name参数进一步提高表达力。
def log(level: Level, msg: => String) {
if (isLoggable(level)) {
log(msg)
}
}
def debug(msg: => String) {
log(DEBUG, msg)
}
def info(msg: => String) {
log(INFO, msg)
}
logger.info("problem:" + getDiagnostic());
"problem:" + getDiagnostic()语句并非在logger.info展开计算，它被延迟计算直至被apply的时候才真正地被评估和计算。
Execute Around
我们经常会遇到一个场景，在执行操作之前，先准备环境，之后再拆除环境。例如XUnit中的setUp/tearDown；操作数据库时，先取得数据库的连接，操作数据后确保释放连接；当操作文件时，先打开文件流，操作文件后确保关闭文件流。
Apply try-finally
为了保证异常安全性，在Java7之前，常常使用try-finally的实现模式解决这样的问题。
public static String process(File file) throws IOException {
BufferedReader bf = new BufferedReader(new FileReader(file));
try {
return bf.readLine();
} finally {
if (bf != null)
bf.close();
}
}
这样的设计和实现存在几个问题：
-
if (bf != null)是必须的，但常常被人遗忘； -
try-finally的样板代码遍布在用户程序中，造成大量的重复设计；
Apply try-with-resources
自Java7，只要实现了AutoCloseable的资源类，可以使用try-with-resources的实现模式，进一步简化上例的样板代码。
public String process(File file) throws IOException {
try(BufferedReader bf = new BufferedReader(new FileReader(file))) {
return bf.readLine();
}
}
但是，在某些场景下很难最大化地复用代码，这使得实现中存在大量的重复代码。例如遍历文件中所有行，并替换制定模式为其他的字符串。
public String replace(File file, String regex, String i) throws IOException {
try(BufferedReader bf = new BufferedReader(new FileReader(file))) {
return bf.readLine().replaceAll(regex, replace);
}
}
Apply Lambda
为了最大化地复用代码，最小化用户样板代码，将资源操作前后的代码保持封闭，使用lambda定制与具体问题相关的处理逻辑。
process使用BufferedProcessor实现行为的参数化。
public static String process(File file, BufferedProcessor p) throws IOException {
try(BufferedReader bf = new BufferedReader(new FileReader(file))) {
return p.process(bf);
}
}
其中，BufferedProcessor是一个函数式接口，用于描述lambda的原型信息。
@FunctionalInterface
public interface BufferedProcessor {
String process(BufferedReader bf) throws IOException;
}
用户使用lambda表达式，使得代码更加简单、漂亮。
process(file, bf -> bf.readLine());
如果使用Method Reference，可增强表达力。
process(file, BufferedReader::readLine);
Apply Scala: Structural Type, Call by Name, Currying
为了最大化地复用资源释放的实现，使用Scala可以神奇地构造一个简单的DSL，让用户更好地实现复用。
Make it Easy to Reuse.
import scala.language.reflectiveCalls
object using {
def apply[R <: { def close(): Unit }, T](resource: => R)(f: R => T) = {
var res: Option[R] = None
try {
res = Some(resource)
f(res.get)
} finally {
if (res != None) res.get.close
}
}
}
R <: { def close(): Unit }中泛型参数R是一个拥有close方法的类型；resource: => R将resource声明为Call by Name，可延迟计算；apply使用了两个参数，并进行了Currying化。
受益于Currying，用户的定制的函数可以使用大括号来增强表达力，using犹如内置的语言特性，得到抽象了的控制结构。
using(Source.fromFile(file)) { source =>
source.getLines
}
因为参数source仅仅使用了一次，可以通过占位符进一步增强表达力。
using(Source.fromFile(file)) { _.getLines }
