我目前正在考虑升级大中型Java代码库中的日志记录机制。消息目前使用类上的静态方法记录，我建议从这个切换到SLF4J或commons-logging之类的东西。Debug
应用程序架构师更喜欢我封装对SLF4J的依赖关系（可能通过将其包装在上述类中）。这将使将来更容易更改日志记录实现。Debug
这对我来说似乎有些过分，因为SLF4J已经在抽象具体的日志记录实现。
是否值得将像 SLF4J 这样的第三方日志记录抽象包装在另一个本地抽象中？
我完全同意你的观点：包装纸的包装纸正在失控。我怀疑架构师没有意识到SLF4J如何能够轻松地包装任何其他日志记录系统，因此“更改实现”在没有另一层包装的情况下是完全可行的。
我猜架构师想要包装包装器（即SLF4J）背后的动机是将您的应用程序与SLF4J隔离开来。显然，从应用程序内部调用 SLF4J API 会创建对 SLF4J 的依赖关系。但是，如下文所述，希望重复应用隔离原则同样合理。这让我想起了理查德·道金斯（Richard Dawkins）的问题：如果上帝创造了宇宙，那么谁创造了上帝？
实际上，您还可以将隔离原则应用于包装SLF4J的包装器。如果SLF4J包装器以某种方式不如SLF4J，那么隔离的原因将无济于事。尽管可能，但包装器与原始包装器相等或超过原始包装器是相当罕见的。SWT可以作为一个值得注意的反例。然而，SWT是一个相当大的项目，成本很高。更重要的是，根据定义，SLF4J包装器依赖于SLF4J。它必然具有相同的通用 API。如果将来出现一个新的且明显不同的日志记录 API，则使用包装器的代码将同样难以像直接使用 SLF4J 的代码一样迁移到新的 API。因此，包装器不太可能使代码适应未来，而是通过添加额外的间接寻址来使其更重。
简而言之，即使您没有更好的事情要做，也不应该浪费时间包装SLF4J，因为包装器的附加值保证接近于零。
该主题也在SLF4J常见问题解答条目中提出。
