是否值得在附加层中包装日志框架？

Question

我目前正在考虑升级中型到大型Java代码库中的日志记录机制.当前使用Debug类上的静态方法记录消息,我建议将其从此切换为SLF4J或commons-logging.

应用程序架构师更喜欢我将依赖性封装在SLF4J上(可能将其包装在前面提到的Debug类中).这样可以更容易地在将来更改日志记录实现.

这对我来说似乎有些过分,因为SLF4J已经在抽象具体的日志记录实现.

是否值得在另一个本土抽象中包装像SLF4J这样的第三方日志抽象？

Answer 1

我完全同意你的观点:包装纸包装纸的包装正在失控.我怀疑架构师没有意识到SLF4J如何能够轻松地包装任何其他日志系统,因此"改变实现"是完全可行的,没有另一层包装.

Answer 2

我想建筑师希望包装包装器(即SLF4J)的动机是将应用程序与SLF4J隔离开来.显然,从应用程序中调用SLF4J API会对SLF4J产生依赖关系.但是,如下所述,想要反复应用隔离原理同样合法.它让我想起理查德道金斯的问题:如果上帝创造了宇宙,那么谁创造了上帝呢？

实际上,您还可以在包装SLF4J的包装器上应用隔离原理.如果SLF4J包装器在某种程度上不如SLF4J,那么隔离的原因就会受到影响.虽然可能,但是包装材料相当于或超过原件是很少见的.SWT可以作为一个值得注意的反例.但是,SWT是一个规模相当大的项目,成本很高.更重要的是,SLF4J-wrapper的定义取决于SLF4J.它必然具有相同的通用API.如果将来会出现一个新的,显着不同的日志API,那么使用包装器的代码将同样难以作为直接使用SLF4J的代码迁移到新API.因此,包装器不太可能在未来证明您的代码,但通过添加额外的间接使其更重.

简而言之,即使您没有更好的事情,也不应该浪费时间包装SLF4J,因为保证包装的附加值保证接近于零.

该主题也在SLF4J FAQ条目中进行了讨论.

Answer 3

我宁愿把它包起来,但不是出于上述原因.如果担心是换出另一个框架的能力,请使用java.util.logging或SLF(java.util.logging不像包装器那样容易使用,但它非常可行),并且交换掉.使用(又一个)包装器的原因是在代码中编写适当的日志记录方法.通常,应用程序需要一个子集,例如所有系统错误都带有异常,或者具有关于何时使用标准日志记录级别的特定指导.这些决策可以封装在一些方法中,在大型代码库中创建更一致的日志记录决策.

但是,如果只是为了使交换实现成为可能,那么就不要重新发明轮子.SLF非常适合这项工作,只需使用它即可.

这有一个例外.如果您的代码无意中被部署到许多可能的应用服务器中,那么您必须确保您的日志记录选择不会冒与框架正在使用的可能较旧或较新版本冲突的风险.