Refactoring to Functions

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

public void info(String msg) {
  if (isLoggable(Level.INFO)) {
    log(msg)
  }
}

这样的设计虽然将状态的查询进行了封装，遵循了LoD原则，但依然存在一个严重的性能问题。无论如何，getDiagnostic都将得到调用，如果它是一个耗时、昂贵的操作，可能成为系统的瓶颈。

Apply Lambda

灵活地应用Lambda惰性求值的特性，可以很漂亮地解决这个问题。

public void log(Level level, Supplier supplier) {
  if (isLoggable(level)) {
    log(supplier.get());
  }
}

public void debug(Supplier supplier) {
  log(Level.DEBUG, supplier);
}

public void info(Supplier 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 }