Refactoring to Functions

重构 · horance · 于 发布 · 986 次阅读
3

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.isLoggablelogger暴露了太多的状态逻辑,违反了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: => Rresource声明为Call by Name,可延迟计算;apply使用了两个参数,并进行了Currying化。

受益于Currying,用户的定制的函数可以使用大括号来增强表达力,using犹如内置的语言特性,得到抽象了的控制结构。

using(Source.fromFile(file)) { source =>
  source.getLines 
}

因为参数source仅仅使用了一次,可以通过占位符进一步增强表达力。

using(Source.fromFile(file)) { _.getLines }

About Me

刘光聪,程序员,敏捷教练,开源软件爱好者,具有多年大型遗留系统的重构经验,对OOFPDSL等领域具有浓厚的兴趣。


「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」和「习惯」以帮助程序员更加快乐高效地编程。
暂无回复。
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。
相关话题
3
重构horance • 最后由 uxyheaven回复
2
3
horance • 最后由 leomustafa回复
5
3
horance • 最后由 sidan001回复
1