Design patterns 在实现适配器模式时是否应该抽象配置？

我们正在讨论使用适配器模式进行日志记录。我不确定这是否是一个好主意，因为我们可能永远不会更改日志实现，但在我们谈到这一点时出现了一个问题：抽象日志模块是否应该隐藏各种日志实现的配置细节

我见过两个项目使用适配器模式来抽象日志记录（其中一个是

在这两个项目中，客户端必须提供的配置取决于日志记录实现。例如，如果使用Log4Net，客户端必须提供一个Log4Net配置文件

当我认为这是适配器模式的不完整实现时，我错了吗？对我来说，如果客户端必须对适配器有一些了解，那么在不破坏客户端的情况下交换实现是不可能的

但我不确定

---

谢谢您的建议。

可以肯定地说，适配器应该隐藏任何特定于适配器的实现细节，以达到纯粹的抽象目的。理想情况下，它应该指定一些类似“Configure”的方法，其中包含基本的配置选项，这些选项应该转换为特定的选项（如果可能的话）

然而，在许多情况下，这可能是极端的。

这取决于具体情况

大体上我同意。如果客户机不需要特定服务实现的特定内容就可以使用它，尽管客户机正在使用某种抽象，那么抽象就被破坏了

但在您的情况下，我认为您混淆了日志库的两个不同客户机

一个客户端是试图将其状态信息发布到世界的应用程序。它不应该以任何方式与配置有关

另一个客户机是为您的应用程序设置环境的人或任何人。此客户端应仅与配置一起考虑

---

因此，您的适配器仅适用于第一个客户端，而此客户端已完成。

从这个角度来看，为不同的实现进行不同的配置似乎是合理的。当然，只要配置是通过文件（而不是通过代码语句）完成的。谢谢你的回答。