摘要：例如中的操作數據庫時，先取得數據庫的連接，操作數據后確保釋放連接當操作文件時，先打開文件流，操作文件后確保關閉文件流。例如遍歷文件中所有行，并替換制定模式為其他的字符串。使用實現行為的參數化。

OO makes code understandable by encapsulating moving parting, but FP makes code understandable by minimizing moving parts. －Michael Feathers

if (logger.isLoggable(Level.INFO)) {
  logger.info("problem:" + getDiagnostic());
}

這個實現存在如下一些壞味道：

重復的樣板代碼，并且散亂到用戶的各個角落；

在logger.debug之前，首先要logger.isLoggable，logger暴露了太多的狀態邏輯，違反了LoD(Law of Demeter)

Eliminate Effects Between Unrelated Things.

logger.info("problem:" + getDiagnostic());

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

這樣的設計雖然將狀態的查詢進行了封裝，遵循了LoD原則，但依然存在一個嚴重的性能問題。無論如何，getDiagnostic都將得到調用，如果它是一個耗時、昂貴的操作，可能成為系統的瓶頸。

靈活地應用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());

在使用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的時候才真正地被評估和計算。

我們經常會遇到一個場景，在執行操作之前，先準備環境，之后再拆除環境。例如XUnit中的setUp/tearDown；操作數據庫時，先取得數據庫的連接，操作數據后確保釋放連接；當操作文件時，先打開文件流，操作文件后確保關閉文件流。

為了保證異常安全性，在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的樣板代碼遍布在用戶程序中，造成大量的重復設計；

自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);
  }
}

為了最大化地復用代碼，最小化用戶樣板代碼，將資源操作前后的代碼保持封閉，使用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);

為了最大化地復用資源釋放的實現，使用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 }