论面向组合子程序设计方法 之 重构

阅读更多
迄今,发现典型的几种疑问是:
1。组合子的设计要求正交,要求最基本,这是不是太难达到呢?
2。面对一些现实中更复杂的需求,组合子怎样scale up呢?

其实,这两者都指向一个答案:重构。


要设计一个完全正交,原子到不可再分的组合子,也许不是总是那么容易。但是,我们并不需要一开始就设计出来完美的组合子设计。

比如,我前面的logging例子,TimestampLogger负责给在一行的开头打印当前时间。
然后readonly提出了一个新的需要:打印调用这个logger的那个java文件的类名字和行号。

分析这个需求,可以发现,两者都要求在一行的开始打印一些东西。似乎有些共性.
这个"在行首打印一些前缀"就成了一个可以抽象出来的共性.于是重构:

interface Factory{
  String create();;
}
class PrefixLogger implements Logger{
  private final Logger logger;
  private final Factory factory;
  private boolean freshline = true;

  private void prefix(int lvl);{
    if(freshline);{
      Object r = factory.create();;
      if(r!=null);
        logger.print(lvl, r);;
      freshline = false;
    }
  }
  public void print(int lvl, String s);{
    prefix(lvl);;
    logger.print(lvl, s);;
  }
  public void println(int lvl, String s);{
    prefix(lvl);;
    logger.println(lvl, s);;
    freshline = true;
  }
  public void printException(int lvl, Throwable e);{
    prefix(lvl);;
    logger.printException(lvl, e);;
    freshline = true;
  }
}

这里,Factory接口用来抽象往行首打印的前缀。这个地方之所以不是一个String,是因为考虑到生成这个前缀可能是比较昂贵的(比如打印行号,这需要创建一个临时异常对象)

另外,真正的Logger接口,会负责打印所有的原始类型和Object类型,例子中我们简化了这个接口,为了演示方便。


然后,先重构timestamp:

class TimestampFactory implements Factory{
  private final DateFormat fmt;
  public String create();{
    return fmt.format(new Date(););;
  }
}


这样,就把timestamp和“行首打印”解耦了出来。


下面添加TraceBackFactory,负责打印当前行号等源代码相关信息。
interface SourceLocationFormat{
  String format(StackTraceElement frame);;
}
class TraceBackFactory implements Factory{
  private final SourceLocationFormat fmt;
  public String create();{
    final StackTraceElement frame = getNearestUserFrame();;
    if(frame!=null);
      return fmt.format(frame);;
    else return null;
  }
  private StackTraceElement getNearestUserFrame();{
    final StackTraceElement[] frames = new Throwable();.getStackTrace();;
    foreach(frame: frames);{
      if(!frame.getClassName();.startsWith("org.mylogging"););{
        //user frame
        return frame;
      }
    }
    return null;
  }
}


具体的SourceLocationFormat的实现我就不写了。

注意,到现在为止,这个重构都是经典的oo的思路,划分责任,按照责任定义Factory, SourceLocationFormat等等接口,依赖注入等。完全没有co的影子。

这也说明,在co里面,我们不是不能采用oo,就象在oo里面,我们也可以围绕某个接口按照co来提供一整套的实现一样,就象在oo里面,我们也可以在函数内部用po的方法来实现某个具体功能一样。


下面开始对factory做一些co的勾当:
先是最简单的:

class ReturnFactory implements Factory{
  private final String s;
  public String create();{return s;}
}


然后是两个factory的串联,

class ConcatFactory implements Factory{
  private final Factory[] fs;
  public String create();{
    StringBuffer buf = new StringBuffer();;
    foreach(f: fs);{
      buf.append(f.create(););;
    }
    return buf.toString();;
  }
}




最后,我们把这几个零件组合在一起:

Logger myprefix(Logger l);{
  Factory timestamp = new TimestampFactory(some_date_format);;
  Factory traceback = new TraceBackFactory(some_location_format);;
  Factory both = new ConcatFactory(
    timestamp, 
    new ReturnFactory(" - ");, 
    traceback,
    new ReturnFactory(" : ");
  );;
  return new PrefixLogger(both, l);;
}


如此,基本上,在行首添加东西的需求就差不多了,我们甚至也可以在行尾添加东西,还可以重用这些factory的组合子。

另一点我想说明的是:这种重构是相当局部的,仅仅影响几个组合子,而并不影响整个组合子框架。


真正影响组合子框架的,是Logger接口本身的变化。假设,readonly提出了一个非常好的意见:printException应该也接受level,因为我们应该也可以选择一个exception的重要程度。


那么,如果需要做这个变化,很不幸的是,所有的实现这个接口的类都要改变。

这是不是co的一个缺陷呢?


我说不是。
即使是oo,如果你需要改动接口,所有的实现类也都要改动。co对这种情况,其实还是做了很大的贡献来避免的:
只有原子组合子需要实现这个接口,而派生的组合子和客户代码,根本就不会被波及到。
而co相比于oo,同样面对相同复杂的需求,往往原子组合子的数目远远小于实际上要实现的语义数,大量的需求要求的语义,被通过组合基本粒子来实现。也因此会减少直接实现这个接口的类的数目,降低了接口变化的波及范围。


那么,这个Logger接口是怎么来的呢?

它的形成来自两方面:

1。需求。通过oo的手段分配责任,最后分析出来的一个接口。这个接口不一定是最简化的,因为它完全是外部需求驱动的。

2。组合子自身接口简单性和完备性的需要。有些时候,我们发现,一个组合子里面如果没有某个方法,或者某个方法如果没有某个参数,一些组合就无法成立。这很可能说明我们的接口不是完备的。(比如那个print函数)。
此时,就需要改动接口,并且修改原子组合子的实现。
因为这个变化完全是基于组合需求的完备性的,所以是co方法本身带来的问题,而不能推诿于oo设计出来的接口。
也因为如此,基本组合子个数的尽量精简就是一个目标。能够通过基本组合子组合而成的,就可以考虑不要直接实现这个接口。
当然,这里面仍然有个权衡:
通过组合出来的不如直接实现的直接,可理解性,甚至可调试性,性能都会有所下降。
而如果选择直接实现接口,那么就要做好接口一旦变化,就多出一个类要改动这个类的心理准备。

如何抉择,没有一定之规。

而因为1和2的目标并不完全一致,很多时候,我们还需要在1和2之间架一个adapter以避免两个目标的冲突。

比如说,实际使用中,我可能希望Logger接口提供不要求level的println函数,让它的缺省值取INFO就好了。

但是,这对组合子的实现来说却是不利的。这时,我们也许就要把这个实现要求的Logger接口和组合子的Logger接口分离开来。(比如把组合子单独挪到一个package中)。



Logger这个例子是非常简单的,它虽然来自于实际项目,但是项目对logging的需求并不是太多,所以一些朋友提出了一些基于实际使用的一些问题,我只能给一个怎么做的大致轮廓,手边却没有可以运行的程序。


那么,下面一个例子,我们来看看一个我经过了很多思考比较完善了的ioc容器的设计。这个设计来源于yan container。


先说一下ioc容器的背景知识。

所谓ioc容器,是一种用来组装用ioc模式(或者叫依赖注射)设计出来的类的工具。
一个用ioc设计出来的类,本身对ioc容器是一无所知的。使用它的时候,可以根据实际情况选择直接new,直接调用setter等等比较直接的方法,但是,当这样的组件非常非常多的时候,用一个ioc容器来统一管理这些对象的组装就可以被考虑。


拿pico作为例子,对应这样一个类:

class Boy{
  private final Girl girl;
  public Boy(Girl g);{
    this.girl = g;
  }
...
}


我们自然可以new Boy(new Girl());

没什么不好的。

但是,如果这种需要组装的类太多,那么这个组装就变成一件累人的活了。

于是,pico container提供了一个统一管理组建的方法:
picocontainer container = new DefaultContainer();;
container.registerComponentImplementation(Boy.class);;
container.registerComponentImplementation(Girl.class);;



这个代码,很可能不是直接写在程序里面,而是先读取配置文件或者什么东西,然后动态地调用这段代码。

最后,使用下面的方法来取得对象:

Object obj = container.getComponentInstance(Boy.class);;


注意,这个container.getXXX,本身是违反ioc的设计模式的,它 主动地去寻找某个组件了。所以,组件本身是忌讳调用这种api的。如果你在组件级别的代码直接依赖ioc容器的api,那么,恭喜你,你终于成功地化神奇为腐朽了。


这段代码,实际上应该出现在系统的最外围的组装程序中。

当然,这是题外话。


那么,我们来评估一下pico先,

1。让容器自动寻找符合某个类型的组件,叫做auto-wiring。这个功能方便,但是不能scale up。一旦系统复杂起来,就会造成一团乱麻,尤其是有两个组件都符合这个要求的时候,就会出现二义性。所以,必须提供让配置者或者程序员显示指定使用哪个组件的能力。所谓manual-wire。
当然,pico实际上是提供了这个能力的,它允许你使用组件key或者组件类型来显示地给某个组件的某个参数或者某个property指定它的那个girl。

但是,pico的灵活性就到这里了,它要求你的这个girl必须被直接登记在这个容器中,占用一个宝贵的全局key,即使这个girl只是专门为这个body临时制造的夏娃。

在java中,遇到这种情况:

void A createA();{
  B b = new B();;
  return new A(b,b);;
}


我们只需要把b作为一个局部变量,构造完A,b就扔掉了。然而,pico里面这不成,b必须被登记在这个容器中。这就相当于你必须要把b定义成一个全局变量一样。
pico的对应代码:

container.registerComponent("b" new CachingComponentAdapter(new ConstructorInjectionComponentAdapter(B.class);););;
container.registerComponent("a", new ConstructorInjectionComponentAdapter(A.class););;


这里,为了对应上面java代码中的两个参数公用一个b的实例的要求,必须把a登记成一个singleton。CachingComponentAdapter负责singleton化某个组件,而ConstructorInjectionComponentAdapter就是一个调用构造函数的组建匹配器。


当然,这样做其实还是有麻烦的,当container不把a登记成singleton的时候(pico缺省都登记成singleton,但是你可以换缺省不用singleton的container。),麻烦就来了。

大家可以看到,上面的createA()函数如果调用两次,会创建两个A对象,两个B对象,而用这段pico代码,调用两次getComponentInstance("a"),会生成两个A对象,但是却只有一个B对象!因为b被被迫登记为singleton了。





2。pico除了支持constructor injection,也支持setter injection甚至factory method injection。(对最后一点我有点含糊,不过就假设它支持)。所以,跟spring对比,除了没有一个配置文件,life-cycle不太优雅之外,什么都有了。

但是,这就够了吗?如果我们把上面的那个createA函数稍微变一下:

A createA();{
  B b = new B();;
  return new A(b, b.createC(x_component););;
}



现在,我们要在b组件上面调用createC()来生成一个C对象。完了,我们要的既不是构造函数,也不是工厂方法,而是在某个临时组件的基础上调用一个函数。

缺省提供的几个ComponentAdapter这时就不够用了,我们被告知要自己实现ComponentAdapter。

实际上,pico对很多灵活性的要求的回答都是:自己实现ComponentAdapter。


这是可行的。没什么是ComponentAdapter干不了的,如果不计工作量的话。

一个麻烦是:我们要直接调用pico的api来自己解析依赖了。我们要自己知道是调用container.getComponentInstance("x_component")还是container.getComponentInstance(X.class)。
第二个麻烦是:降低了代码重用。自己实现ComponentAdapter就得自己老老实实地写,如果自己的component adapter也要动态设置java bean setter的话,甭想直接用SetterInjectionComponentAdapter,好好看java bean的api吧。


其实,我们可以看出,pico的各种ComponentAdapter正是正宗的decorator pattern。什么CachingComponentAdapter,什么SynchronizedComponentAdapter,都是decorator。

但是,这也就是decorator而已了。因为没有围绕组合子的思路开展设计,这些decorator显得非常随意,没有什么章法,没办法支撑起整个的ComponentAdapter的架构。

下一章,我们会介绍yan container对上面提出的问题以及很多其他问题的解决方法。

yan container的口号是:只要你直接组装能够做到的,容器就能做到。
不管你是不是用构造函数,静态方法,java bean,构造函数然后再调用某个方法,等等等等。
而且yan container的目标是,你几乎不用自己实现component adapter,所有的需求,都通过组合各种已经存在的组合子来完成。


对我们前面那个很不厚道地用来刁难pico的例子,yan的解决方法是:


b_component = Components.ctor(B.class);.singleton();;
a_component = Components.ctor(A.class);
  .withArgument(0, b_component);
  .withArgument(1, b_component.method("createC"););;


b_component不需要登记在容器中,它作为局部component存在。
是不是非常declarative呢?


下一节,你会发现,用面向组合子的方法,ioc容器这种东西真的不难。我们不需要仔细分析各种需求,精心分配责任。让我们再次体验一下吊儿郎当不知不觉间就天下大治的感觉吧。

待续。

你可能感兴趣的:(设计模式,OO,IOC,Bean,配置管理)