Logger MVC体系的Lazy Model设计思路

Log4J 和 JDK Logging 属于经典的过度设计的例子。非常复杂，非常难用。
:D just kidding. Logger体系是非常灵活强大的。

Logger体系也可以看作是MVC结构。
其中的View做的最好，Formatter, Outputer，都可以任意组合。
Controller部分也不错，能够很好地支持Logger层次结构的控制。

[b]Model部分比较简单，就是让用户提供String。
这里就有一个问题，为什么不接受Object呢？
这不仅是使用方便的问题，也是处于性能的考虑。
[/b]
我们知道，生产环境中，为了性能，Log能够被关掉。
但是，Model提供部分，却不能关掉。比如，

List longList = ....
log.info( longList.toString() );

虽然可以关闭Log，Log可以不输出了。但是 longList.toString() 还是要执行。而longList.toString() 有可能很耗费时间。
如何实现Logger的Lazy Model?

我的初步想法是，需要 Logger接受 Object。然后Logger内部自己调用toString()来获取Model。
[b]List longList = ....
log.info( longList);

只有需要调用toString的时候，才调用。[/b]

另外也可以提供一个通用Wrapper。对应更复杂的情况。

public class DelegateString{
   Object obj;
   public DelegateString(object obj){
           this.obj = obj;
    }

   public String toString(){
         return obj.toString();
   }
}

上面的代码就变成
List longList = ....
log.info( new DelegateString(longList) );

或者使用Local Class，和Nested Class。访问method内部的 final局部变量。

final List longList = ....
log.info( 
   new Object(){
      public String toString(){
         return longList.toString();
      }
   }
);

写起来确实比较难看，但是效率上有些好处。关闭了Log之后，longList.toString()就不用执行了。

[b]这种Wrapper的方法，可以用在包装好几个Object，或者比较复杂的对象结构的显示需求。
这个例子里面当然不用，直接传入 longList就行了。

假设String不是Final，可以继承，那也可以采用这种Wrapper的折衷方法。要命的是，String竟然是Final的，无法覆盖String的toString方法，所以，需要修改参数类型为Object（或者其他的interface）
[/b]


假如Java支持Code Block (and clousure, dynamic scope)。
那么代码可以写成
final List longList = ....
log.info( {return longList.toString();});

看起来就好看了许多。

只是个初步想法，看看大家有什么好的意见，解决类似于这类Logger Lazy Model的问题。

----------

Tomhornson提出的一个建议：
可以先检测log状态，
if(logger.infoEnable()){
log.info(... )
}

是的。看到很多代码这么写。
这么写，也比较麻烦。需要多写一个 if。