.net - 相互依赖的子/父命名空间是代码异味吗？

Question

我最近在查看我的主要个人项目的一些依赖关系图，我注意到嵌套命名空间中的对象之间存在相互依赖关系。例如，我在 MyNamespace.Foo 中有一个对象在 MyNamespace.Foo.Interfaces 中实现了一个通用接口(interface)将该对象作为接口(interface)中的通用参数。

namespace MyNamespace.Foo
{
    internal class Foo : MyNamespace.Foo.Interfaces.IFoo<Foo>
    { }
}

在这种情况下。依赖分析工具(VS2010 beta)合理地认为接口(interface)的通用“实例化”(为了讨论，我知道这不是c++)是接口(interface)命名空间的成员，然后依赖于其父命名空间。

经过我的一些考虑，我或多或少地得出结论，在我的特定情况下，我现有的设计是一种代码气味。我应该合并 Interfaces命名空间到父 Foo 命名空间。 (如果我希望客户端通过 Foo 使用 IFoo，则要求客户端向下钻取一个额外的层到接口(interface)命名空间是愚蠢的。)但是在一般情况下这是真的吗？

应该如何管理命名空间间的依赖关系？应该“更广泛”的命名空间(如 MyNamespace.Foo 通常依赖于“更窄”的命名空间(如 MyNamespace.Foo.Interfaces)，还是应该更窄的命名空间依赖更广泛的命名空间？还是有更好、更微妙的答案？

Answer 1

在关于您的示例的特定情况下，我将合并 Interfaces命名空间到父命名空间。

一般来说，我认为更窄的命名空间应该依赖于更广泛的类或接口(interface)，或者是共享父命名空间的子类或接口(interface)。第二种情况很典型，如果您安排了命名空间，以便模型命名空间具有共享类或接口(interface)，这些类或接口(interface)描述了您的代码试图解决的问题的模型。

我还应该注意，我认为这些规则不一定适用于第三方依赖项。例如，取决于 Spring.NET 中狭窄命名空间中的代码在您的代码中不构成代码气味。