|
一、释名
为什么叫精神？
如果你熟悉c++，那么你可能知道一个叫做”spirit”的parser库。它利用c++的模板元编程能力，使用c++语言本身提供了一个递归下降文法解析的框架。 我这里介绍的jparsec库，就是一个java里面的递归下降文法解析框架。
不过，它并非是spirit的java版本。
Jparsec的蓝本来自Haskell语言的parsec库。Parsec是一个基于monad的parser组合子库。
这个库的目的是要在java中提供一个类似parsec, spirit的库，这种组合子库并非c++的专利，java/c#也可以做到。这个库还将在java5.0上被改写，类型安全上它将也不再逊色于c++。
那么，为什么叫“函数式”呢？java是面向对象的嘛。
如果你使用过haskell, lisp等语言，这个函数式不用解释你也知道是怎么回事了。
如果你是一个老牌的c++/java程序员，那么这里还要稍微解释一下。当然如果您对这些虚头八脑的名词不感兴趣，那么，你尽可以跳过这一章，不知道什么是“函数式”，并不会影响你对这个库的理解的。
C++这几年随着gp的普及，“函数式”这个老孔乙己逐渐又被人从角落里面拽了出来。一个c++程序员所熟悉的“函数式”很可能是stl的for_each, transform，count_if这些函数。
怎么说呢，就象我不能否定str.length()这个调用属于OO一样，我也无法说for_each, transform不是函数式。
但是，“函数式”的精髓不在于此。
一般归纳起来，就像我们说OO是什么多态，封装，继承一样，“函数式”的特征被总结为：
1.无副作用。
2.高阶函数。
3.延迟计算
而最最有意义的（至少我认为如此），是基于高阶函数的函数组合能力。一些人把这叫做glue。
简短地说，什么让函数式编程如此强大？是用简单的函数组合出复杂函数的能力。
我可以想象，说到这里，你还是一头雾水。“什么是组合？1+1不是也把两个1组合成2了吗？new A(new B(), new C())不也是从B和C组合成A了？”
为了直观，我们来举个例子吧。
假设，我们在package predicates内部有一个接口：
| interface SPredicate{
boolean is(String s);
} |
我们有几个基本的实现：
| class IsEmpty implements Spredicate{
public boolean is(String s){return s.length()==0;}
} |
这个实现判断字符串是不是空。
| class IsCaptialized implements Spredicate{…} |
这个实现判断这个字符串是不是大写打头。
| class IsLowercase implements Spredicate{…} |
这个实现判断字符串是不是全小写。
| class IsEqual implements Spredicate{
Private final String v;
Public Boolean is(String s){return s.equals(v);}
IsEqual(String v){this.v = v;}
} |
这个实现判断这个字符串是否和制定的字符串相等。
类似的基本实现还可以有很多。
下面，假如我们希望实现一个Spredicate，它要判断“这个字符串是个小写字符串，或者等于hello”。
我们怎么办呢？
我们当然可以这样：
| class Predicate1 implements Spredicate{
Boolean is(String v){
Return v.isLowercase() || v.equals(“hello”);
}
} |
只不过，这样一来，我们没有重用IsEqual和IsLowercase这两个类的代码，虽然逻辑上我们是和这两个类有重叠。
我们当然也可以直接调用IsEqual和IsLowercase的代码，如：
| class Predicate1 implements Spredicate{
Boolean is(String v){
return new IsEqual().is(v) || new IsLowercase().is(v);
}
}
|
只不过，这样的代码是过程式的，非常死板。
如果我再有一个IsEqual或者IsCapitalized的逻辑呢？还要再写一个Predicate2类么？
如果你OO有一定功底，一定可以看出，这个代码不符合IOC原则，在不该new的地方new了。
好，知错就改，根据IOC原则，我们重构如下：
| class OrPredicate implements Spredicate{
private final Spredicate p1;
private final Spredicate p2;
public Boolean is(String s){
return p1.is(s) || p2.is(s);
}
} |
构造函数我就不写了。
如此，Predicate1我们就可以写成new OrPredicate(new IsLowercase(), new IsEqual(“hello”));
类似的，我们可以加上AndPredicate, NotPredicate, XorPredicate.
这样，基本上就可以覆盖所有的布尔操作了。
我们在写我们自己的Predicate的时候，就根本不必写is函数，甚至可以忘记is函数的存在。我们面对的不再是一个有着一个boolean is(String)签名的接口，而是一个可以通过各种规则组合的类型。
一个Predicate可以简单如new NotPredicate(p)，也可以复杂如：
| new AndPredicate(new OrPredicate(a,new XorPredicate(b,c), d)); |
擦擦眼睛，现在，我们等于自己制造出一个可以用一些特定规则组合的类型，而Spredicate的签名甚至都不再重要了。我们的客户程序从操作字符串变成了操作各种Spredicate对象，这已经是更高一级的抽象了。
为了表现这一点，让我们把Spredicate改成abstract class, 并把is()函数改成包私有（这样我们外面的用户程序就再也看不到这个函数了）。
等等！你可能发现了，现在我们虽然可以自由组合不同的Spredicate对象，但是组合之后有什么用呢？is函数看不见了，难道我们就是为了组合而组合吗？
不错，一个完整的组合子，还缺最后一小块。
让我们在predicates包内部再加上一个utility函数：
| public Boolean runPredicate(Spredicate p, String s){
Return p.is(s);
} |
好了，功德圆满，我们可以用这个runPredicate函数来执行一个组合好了的Spredicate对象，而不用关心这个对象内部的is函数。
你可能有点怀疑。RunPredicate(p, s)和p.is(s)有什么区别？
呵呵，现在是没什么区别。下面我们来看看什么时候这种封装有明显的好处。
假设根据实现需要我们的Spredicate.is函数不是现在看到的这么简单，它可能是：
Boolean is(String s, PredicateContext ctxt);
PredicateContext对象负责存储并传递一些包局部的信息。
此时，我们很有可能不希望把这个签名对外公布。因为这个签名非常有可能变化，它是一个包的实现细节。PredicateContext甚至都是个包私有的类型。
此时，把is函数隐藏起来就是必要的了。对外，我们只公开一个runPredicate工具函数：
| public Boolean runPredicate(String s, Spredicate p){
final PredicateContext ctxt = new PredicateContext();
return p.is(s, ctxt);
} |
好，现在客户程序可以随意组合各个Predicate对象，最后用runPredicate函数运行。而包内部在演化时，完全可以根据需要随时改动is函数的签名，增加新的状态。
这，就是一个完整的组合子的例子。
|
