论面向组合子程序设计方法 之五 新约

每个小孩刚开始走路的时候都是跌跌撞撞的。 我们不自量力,妄图踩着上帝的步伐前进。结果就是这么几个简单的象白开水似的类。失望吗?是不是造物试图模仿造物主本身就是一种可笑的狂妄呢?

别急,让我们失声痛哭之前先看看我们这几步走的是不是一钱不值。

1。logger可以把信息打印到log文件中。

容易,直接创建一个WriterLogger就好了。

2。不同的重要程度的信息也许可以打印到不同的文件中?象websphere,有error.log, info.log等。 如果这样,那么什么重要程度的信息进入error.log,什么进入warning.log,什么进入info.log也需要决定。

不同的文件吗?好办啊。就是不同的PrintWriter对象了。 java代码:

Logger err_log = writer(err_writer); 
Logger warning_log = writer(warning_writer); 
Logger info_log = writer(info_writer);

各个文件记录不同重要程度的信息是么? java代码:

err_log = filter(ERROR, err_log, nop()); 
warning_log = filter(WARNING, warning_log, nop()); 
info_log = filter(INFO, info_log, nop());

最终把三个不同的logger串联起来就是了: java代码:

Logger logger = sequence(err_log, warning_log, info_log);

3。也许可以象ant一样把所有的信息都打印到一个文件中。

这就更简单了,就一个是WriterLogger。

4。每条logging信息是否要同时打印当前的系统时间?也是一个需要抉择的问题。

拿不定主意是么?没关系,想好了再告诉我。 反正,如果你需要系统时间,我只需要 java代码:

logger = timestamp(logger);

5。不仅仅是log文件,我们还希望能够在标准错误输出上直接看见错误,普通的信息可以打印到log文件中,对错误信息,我们希望log文件和标准输出上都有。

可以创建针对标准输出的Logger,然后和打印log 文件的logger串联起来。 java代码:

Logger std_logger = writer(new PrintWriter(System.err)); 
std_logger = ignore(ERROR, std_logger); 
logger = sequence(std_logger, logger); 

6。标准输出上的东西只要通知我们出错了就行,大概不需要详细的stack trace,所以exception stack trace可以打印到文件中,而屏幕上有个简短的exception的message就够了。

这里需要对std_logger稍微改写一下: java代码:

PrintWriter out = new PrintWriter(System.err); 
std_logger = new ErrorMessageLogger(out, writer(out)); 
std_logger = ignore(ERROR, std_logger, nop()); 

用ErrorMessageLogger来改写对异常的log逻辑。

7。warning似乎也应该输出到屏幕上。

好啊。就是把ignore函数里面的ERROR换成WARNING就好了 java代码:

std_logger = ignore(WARNING, std_logger, nop());

8。不管文件里面是否要打印当前系统时间,屏幕上应该可以选择不要打印时间。

对std_logger不掉用timestamp就是了。

9。客户应该可以通过命令行来决定log文件的名字。

这条和logger组合子其实没什么关系。

10。客户可以通过命令行来决定log的细节程度,比如,我们只关心info一样级别的信息,至于debug, verbose的信息,对不起,不要打印。

生成那个最终使用的Logger对象的时候,再ignore一下就行了:

java代码:

logger = ignore(some_level, logger, nop());

11。neptune生成的是一些Command对象,这些对象运行的时候如果出现exception,这些exception会带有execution trace,这个execution trace可以告诉我们每个调用栈上的Command对象在原始的neptune文件中的位置(行号)。 这种exception叫做NeptuneException,它有一个printExecutionTrace(PrintWriter)的方法来打印execution trace。 所以,对应NeptuneException,我们就不仅仅是printStackTrace()了,而是要在printStackTrace()之前调用printExecutionTrace()。

NeptuneExceptionLogger就是给这个准备的呀。

12。neptune使用的是jaskell语言,如果jaskell脚本运行失败,一个EvaluationException会被抛出,这个 类有一个printEvaluationTrace(PrintWriter)的方法来打印evaluation trace,这个trace用来告诉我们每个jaskell的表达式在脚本文件中的位置。 所以,对应EvaluationException,我们要在printStackTrace()之前,调用printEvaluationTrace()。

JaskellExceptionLogger

13。execution trace和evaluation trace应该被打印到屏幕上和log文件两个地方。

这就是说,上面两个Logger应该被应用到std_logger和logger两个对象中。

14。因为printExecutionTrace()和printEvaluationTrace()本身已经打印了这个异常的getMessage(),所以,对这两种异常,我们就不再象对待其它种类的异常那样在屏幕上打印getMessage()了,以免重复。

就是说,一旦一个exception被发现是NeptuneException,那么ErrorMessageLogger就要被跳过了。 java代码:

    final Logger err_logger = new ErrorMessageLogger(writer); 
    final Logger jaskell_logger = new JaskellExceptionLogger(writer, err_logger); 
    final Logger neptune_logger = new NeptuneExceptionLogger(writer, jaskell_logger); 
    return neptune_logger;

这个neptune_logger先判断异常是不是NeptuneException,如果是,直接处理,否则,传递给 jaskell_logger。jaskell_logger继续判断,如果不是它感兴趣的,再传递给ErrorMessageLogger来做最后的缺 省处理。

15。也许还有一些暂时没有想到的需求, 比如不是写入log文件,而是画个图之类的变态要求。

放马过来吧。看我们的组合子能不能对付。

很惊讶地发现,就这么几个小儿科似的积木,就似乎全部解决了曾让我们烦恼的这些需求?

为了给大家一个完整的印象,下面是我实际项目中使用这些组合子应对上面这些需求的代码: java代码:

public class StreamLogger { 
  private final OutputStream out; 
  
  /** 
   * To create a StreamLogger object. 
   * @param out the OutputStream object that the log message should go to. 
   */ 
  public StreamLogger(OutputStream out) { 
    this.out = out; 
  } 
  
  /** 
   * To get the OutputStream that the log messages should go to. 
   */ 
  public OutputStream getStream() { 
    return out; 
  } 
  private static Logger getBaseLogger(PrintWriter writer){ 
    final Logger nop = new NopLogger(); 
    final Logger base = Loggers.logger(writer); 
    final Logger neptune_logger = new NeptuneExceptionLogger(writer, nop); 
    final Logger jaskell_logger = new JaskellExceptionLogger(writer, nop); 
    return Loggers.sequence( 
        new Logger[]{neptune_logger, jaskell_logger, base} 
    ); 
  } 
  private static Logger getEchoLogger(PrintWriter writer){ 
    return new ErrorMessageLogger(writer); 
  } 
  private static Logger getErrorLogger(PrintWriter writer){ 
    final Logger err_logger = new ErrorMessageLogger(writer); 
    final Logger jaskell_logger = new JaskellExceptionLogger(writer, err_logger); 
    final Logger neptune_logger = new NeptuneExceptionLogger(writer, jaskell_logger); 
    return neptune_logger; 
  } 
  /** 
   * Get the Logger instance. 
   * @param min_level the minimal critical level for a log message to show up in the log. 
   * @return the Logger instance. 
   */ 
  public Logger getDefaultLogger(int min_level){ 
    final PrintWriter writer = new PrintWriter(out, true); 
    final PrintWriter err = new PrintWriter(System.err, true); 
    final PrintWriter warn = new PrintWriter(System.out, true); 
    final Logger all = Loggers.sequence(new Logger[]{ 
        Loggers.ignore(getErrorLogger(err), Logger.ERROR), 
        Loggers.filter(getEchoLogger(warn), Logger.WARNING), 
        getBaseLogger(writer) 
      } 
    ); 
    return Loggers.ignore(all, min_level); 
  } 
}

为了偷懒,我没有用配置文件,就是把这些策略硬编码进java了。好在上面的代码非常declarative,改起来也很容易。

没习惯读代码的朋友。这里奉劝还是读一读吧。很多时候,代码才是说明问题的最好手段。我相信,只有读了代码,你才能真正尝到CO的味道。

有朋友问,你这个东西和decorator pattern有什么区别呀?乍看上去,还真是长得差不多呢。不都是往现有的某个对象上面附加一些功能吗? 也许是把。我不知道象SequenceLogger这种接受一个数组的,是否也叫做对数组的decorator;也不知道IgnoreLogger接受了两个Logger对象,这个decorator究竟是修饰谁的呢?

其实,叫什么名字无所谓。我这里要讲的,是一种从基本粒子推演组合的思路。形式上它也许碰巧象decorator, 象ioc。但是正如workinghard所说(这句话深得我心),思路的切入点不同。

如果你仔细看上面的代码,也许你会有所感觉:对Logger的千奇百怪的组合本身已经有点象一个程序代码了。 如果用伪码表示:

java代码:

  all_logger = ignore messages below ERROR for getErrorLogger(err); 
          filter messages except WARNING for getEchoLogger(warn); 
          baseBaseLogger(writer); 
  ignore messages below lvl for all_logger;

当组合子越来越多,需求越来越复杂,这个组合就会越来越象个程序。

这里,实际上,(至少我希望如此),我们的思维已经从打印什么什么东西上升为在Logger这个级别的组装了。

这也就是所谓higher order logic的意思。

所谓combinator-oriented,在这里,就体现为系统性地在高阶逻辑的层面上考虑问题,而不是如decorator那样的零敲碎打的几个功能模块。 大量的需求逻辑被以声明式的方式在高阶逻辑中实现,而基本的组合子只负责实现原字操作。

当然,缺点也是明显的,对此我不讳言:

高阶逻辑不容易调试,当我们使用一个组合了十几层的复杂的Logger对象的时候(真正用了co这种情况不少见),一旦出现bug,跟踪的时候我们就会发现象是陷入了一个迷宫,从一个组合子跟踪进入另一个组合子,绕来绕去。

另外,异常的stack trace也无法反映组合层次关系,造成错误定位麻烦。

这也许不是co本身的问题,而是因为java这种oo语言对co没有提供语言上的支持。但是无论如何,这对在java中大规模使用co造成了障碍。

也许你还无法理解。平时我们在java中用那么几个decorator,本身非常简单,所以debug, trace都不是问题。可是,一旦oriented起来,情况就不同了。街上有两辆车和成千上万辆车,对交通造成的压力截然不同。

还有朋友,对co如何把握有疑问。难道co就是瞎猫碰死耗子么?

其实,无论co还是oo,对设计者都是有一定要求的。 oo要求你了解需求,并且经验丰富,也要有一点点运气。 co也要求经验,这个经验是设计组合子系统的经验。什么样的组合子是好的?怎么才算是足够简单?什么组合规则是合理的?等等,这些,也有规律可循,就像oo的各种模式一样。同时,也可以refactor。毕竟,怎么简单地想问题比怎么分解复杂问题可能还是要容易掌握一点。

不过,co对经验的要求稍微小一点,但是对数学和逻辑的基本功要求则多了一点。有了一些数学和逻辑方面的基本功,那么设计组合子就会轻松的多。

co也要有一点点运气。所以遇到你怎么想也想不明白的情况,就别死抗啦,也许这个问题就抽象不出组合子来,或者以我们普通人的智慧抽象不出来。

co是银弹吗?当然不是,至少以我的功力没有这种自信。 遇到复杂的问题我也是先分解需求,面向接口的。只有问题的规模被控制在了一定的范围,我才会试图用co来解决问题。靠着对co的一些经验和感觉,一旦发现了可以组合子化的概念,成果会非常显著。

而且,co和oo关注的层面也不同。co是针对一个单独的概念(这点倒有点象ao),一点一点演绎,构成一个可以任意复杂的系统,一个好的co也 会大大减少需要引入的概念数。而oo是处理大量互相或者有联系,或者没有联系的概念,研究怎么样把一个看上去复杂的系统的复杂度控制住。所以两者并不是互 相排斥的。自顶向下,自底向上,也许还是两手一起抓更好些。

这段时间应用co做了几个软件后,感觉co最擅长的领域是: 问题域有比较少的概念,概念简明清晰(比如logger, predicate, factory,command),但是对概念的实现要求非常灵活的场合。 这种时候,用oo就有无处下嘴之感。毕竟概念已经分解了,职责也清楚,就是怎么提供一个可以灵活适应变化的体系,而对这个,oo并没有提供一个方法论。基本上就是用po的方法吭哧吭哧硬做。而co此时就可以大展用武之地。弥补这个空隙。

看过圣经的,也许有感觉,旧约里面的上帝严厉,经典,就像是一个纯粹的fp语言,每个程序员都被迫按照函数式,组合子的方式思考问题,你感觉困难?那是你不够虔诚。你们人不合我的心意,我淹死你们!

而新约里面,明显添加了很多人情味儿。上帝通过自己的儿子和人们和解了。既然淹死一波,再来一波还是这样,那么是不是说大家应该各让一步呢? co和oo,既然各自都不能宣称自己就是银弹,那么为什么不能拉起手来呢?我们不是神,不可能真正按照神的方式用基本粒子组合演化世界,所以就别 象清教徒一样苦苦追求不可能的目标了。但是,上帝的组合之道毕竟相当巧妙,在有些时候荆棘里面出现火焰的时候,我们又何必固执地拒绝造物主的好意呢?礼貌 地说一声:“谢了!老大”。不是皆大欢喜?

这一节我们继续讲解了这个logging的例子。实际上,logging是一个非常简单的组合子,下面如果大家对这个例子有疑问,我会尽力解答。

然后,我们会进军下一个例子。