Logger MVC体系的Lazy Model设计思路
程序员文章站
2022-07-02 17:45:49
...
Log4J 和 JDK Logging 属于经典的过度设计的例子。非常复杂,非常难用。
:D just kidding. Logger体系是非常灵活强大的。
Logger体系也可以看作是MVC结构。
其中的View做的最好,Formatter, Outputer,都可以任意组合。
Controller部分也不错,能够很好地支持Logger层次结构的控制。
Model部分比较简单,就是让用户提供String。
这里就有一个问题,为什么不接受Object呢?
这不仅是使用方便的问题,也是处于性能的考虑。
我们知道,生产环境中,为了性能,Log能够被关掉。
但是,Model提供部分,却不能关掉。比如,
List longList = ....
log.info( longList.toString() );
虽然可以关闭Log,Log可以不输出了。但是 longList.toString() 还是要执行。而longList.toString() 有可能很耗费时间。
如何实现Logger的Lazy Model?
我的初步想法是,需要 Logger接受 Object。然后Logger内部自己调用toString()来获取Model。
List longList = ....
log.info( longList);
只有需要调用toString的时候,才调用。
另外也可以提供一个通用Wrapper。对应更复杂的情况。
上面的代码就变成
List longList = ....
log.info( new DelegateString(longList) );
或者使用Local Class,和Nested Class。访问method内部的 final局部变量。
写起来确实比较难看,但是效率上有些好处。关闭了Log之后,longList.toString()就不用执行了。
这种Wrapper的方法,可以用在包装好几个Object,或者比较复杂的对象结构的显示需求。
这个例子里面当然不用,直接传入 longList就行了。
假设String不是Final,可以继承,那也可以采用这种Wrapper的折衷方法。要命的是,String竟然是Final的,无法覆盖String的toString方法,所以,需要修改参数类型为Object(或者其他的interface)
假如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。
:D just kidding. Logger体系是非常灵活强大的。
Logger体系也可以看作是MVC结构。
其中的View做的最好,Formatter, Outputer,都可以任意组合。
Controller部分也不错,能够很好地支持Logger层次结构的控制。
Model部分比较简单,就是让用户提供String。
这里就有一个问题,为什么不接受Object呢?
这不仅是使用方便的问题,也是处于性能的考虑。
我们知道,生产环境中,为了性能,Log能够被关掉。
但是,Model提供部分,却不能关掉。比如,
List longList = ....
log.info( longList.toString() );
虽然可以关闭Log,Log可以不输出了。但是 longList.toString() 还是要执行。而longList.toString() 有可能很耗费时间。
如何实现Logger的Lazy Model?
我的初步想法是,需要 Logger接受 Object。然后Logger内部自己调用toString()来获取Model。
List longList = ....
log.info( longList);
只有需要调用toString的时候,才调用。
另外也可以提供一个通用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()就不用执行了。
这种Wrapper的方法,可以用在包装好几个Object,或者比较复杂的对象结构的显示需求。
这个例子里面当然不用,直接传入 longList就行了。
假设String不是Final,可以继承,那也可以采用这种Wrapper的折衷方法。要命的是,String竟然是Final的,无法覆盖String的toString方法,所以,需要修改参数类型为Object(或者其他的interface)
假如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。