Question

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

负责Config模块的团队实现了一个仅包含2个类的接口。 2个类，负责获取，缓存和提供特定值（通过属性）。

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

在我看来，对于像获取配置值这样的东西，给出一个界面可以显示我将能够访问的值，但不是一个类（这些实现，例如属性不受接口）。

-edit - 界面如下所示：

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

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

这些是非常有经验的开发人员，而我不是，所以你对此有何看法？

Answer 1

这里有很多事情要发生......

IConfigurationResolver接口中非抽象类的引用是代码气味，违反了“程序到接口，而不是实现”主体（What does it mean to "program to an interface"?）。

您希望通过接口明确显示配置参数是一个很好的，并且符合意图显示接口的概念（如Eric Evans'Domain Driven Design中所述）。

但是，如果你有很多配置值，这个界面最终可能会有很多方法。这就是您的域的知识进入的地方 - 将“配置世界”分解为一组内聚接口，每个接口用于配置应用程序的单独方面本身就是一项技能，并且与{我在'SOLID。 Lowy的Programming .NET components讨论了合同重新分解的问题，并且粗略指南建议每个接口使用3-5种方法。

我猜想“重新配置配置”的愿望是当前界面上两种方法存在的根源。

Answer 2

SOLID原则之一是界面隔离原理 “许多特定于客户端的接口优于一个通用接口。”

http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

“仅包含2个类的界面”是什么意思？只有两个类实现了这个接口？

我认为这是一个糟糕的设计，在我看来，它会更好定义可以通过接口访问的所有配置值，但不能实现此行为的实际类。

不确定我理解你的问题 - 是的，你应该参考界面，而不是直接引用课程？

Answer 3

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

只要您想为sinlge行为（如Bean Validation API）提供多个实现，或者如果您想限制应该为类的不同用户使用的方法，接口就有意义。

接口应该有多复杂？

3 个答案: