C# 接口应该有多复杂？

我们正在一个项目中工作，其中将有一个共享配置，该配置需要由解决方案的多个部分访问

负责配置模块的团队实现了一个仅由2个类组成的接口。2个类，负责获取、缓存和提供特定值（通过属性）

我觉得这是一个糟糕的设计，在我看来，最好定义可以通过接口访问的所有配置值，而不是实现此行为的实际类

在我看来，对于像获取配置值这样的东西，更合理的做法是提供一个接口，向我显示我可以访问哪些值，而不是一个类（该实现例如属性不受接口控制）

-编辑- 界面如下所示：

public interface IConfigurationResolver
{
    GeneralConfiguration GetGeneralConfiguration(string Id);
    SpecificConfiguration GetSpecificConfiguration(string Id);
}

它由一个类实现。我的意思是，这个接口实际上只定义了两个类，每个类负责提供配置值，而我认为如果接口不关心这些细节，而应该自己提供配置值，那就更好了

---

他们是非常有经验的开发人员，而我不是，那么你对此持什么立场呢？

一个可靠的原则是 界面分离原理 “许多特定于客户端的接口比一个通用接口要好。”

您所说的“仅由两个类组成的接口”是什么意思？只有两个类实现这个接口

我觉得这是一个糟糕的设计，在我看来，最好是 定义可通过接口访问的所有配置值，但不包括 实现此行为的实际类

---

不确定我是否理解您的问题-是的，您应该参考接口，而不是直接参考类？

我认为这种方法没有任何问题。一个OO原则是隐藏。只要类的内部结构是用私有方法或子类隐藏的，就根本不需要使用任何接口

---

只要您想为sinlge行为（如Bean验证API）提供多个实现，或者想要限制一个类的不同用户可以使用的方法，接口就有意义了。

这里有很多事情

IConfigurationResolver

接口中非抽象类的引用是一种代码味道，违反了“程序到接口，而不是实现”原则（）

您希望通过接口显式地显示配置参数，这是一个很好的愿望，并且符合意图显示接口的概念（如Eric Evans中所述）

然而，如果您有大量的配置值，那么这个接口最终可能会有大量的方法。这就是领域知识的来源——将“配置的宇宙”分解为一组内聚接口，每个接口用于配置应用程序的一个单独方面，这本身就是一项技能，并且与中的“I”相关。Lowy’s讨论了合同重分解的问题，作为一个粗略的指南，建议每个接口使用3-5种方法

---

我猜“重新考虑配置”的愿望是当前接口上存在这两种方法的根源

我认为没有违反这一原则，因为在我们的案例中，配置可以被视为一个粒度实体。拆分它没有多大意义，因为所有的值都可以在任何地方访问。好吧，这很公平。我不完全理解你的问题，因为题目是接口应该有多复杂，但是你的问题的主体暗示你在问你是否应该引用接口而不是类？你能提供更多关于这个问题的信息吗？你的编辑现在更清楚了。在不知道这两个类的属性是什么和有多少的情况下，它会在imo中来回摆动。现在大约有40个（这可能会随着时间的推移而改变）。但是它们非常相似，包含常规配置、参数或公式。如果不更广泛地理解应用程序：大小、功能、生命周期等等，几乎不可能对此进行评论。这些都是可能影响最佳实践的因素。例如，对于生命周期较短的产品，可维护性不如长期产品重要。开发人员的工作最好花在配置类以外的事情上。配置在这个项目中实际上非常重要。这是一个运行至少5年（可能更长）的web应用程序。它将使用户能够在不同（但非常相似）的系统上工作。这些系统将需要大量的参数和公式，这些参数和公式因系统而异，并且可能随时间而变化。对不起，我真的说不清我们到底在说什么