同一文件中的 C# 接口(interface)和实现 - 好主意吗？

Question

我最近看到一些 C# 代码，其中接口(interface)声明和实现在同一个文件中，就像这样

namespace MyNameSpace.Foo
{
    public interface IFoo{
        void DoThis();
    }
    public class Foo : IFoo {
        public void DoThis();
    }
}

乍一看，在同一个文件中声明和实现似乎都是错误的，但实际上有好处。例如当您在 Visual Studio 中转到定义时，接口(interface)和实现位于同一个文件中。这种方法并不禁止您拥有接口(interface)的其他实现，例如单元测试可能需要的实现。对于只有一个实现的接口(interface)，我认为这是一种实用的方法。

好主意还是坏主意？

扩展问题:
当你有一个接口(interface)引用时，人们如何使用 Visual Studio 导航到一个实现IFoo myFoo = FooFactory.getFoo(MY_FOO);声明。有没有办法让我获得 IFoo 的实现列表，因为这是我真正感兴趣的。

Answer 1

我的建议是始终遵循每个 .cs 文件一个项目的规则，无论是枚举声明、接口(interface)还是类。 .cs 文件的名称应与其包含的内容的名称相匹配。

规则简单，易于遵循。我们使用 StyleCop在内部对此进行监管。

如果您将此方法与命名空间的合理使用相结合，那么这应该意味着您在 Visual Studio 中的解决方案资源管理器 View 可以轻松导航项目中的组件。注意 ReSharper gives an alternative approach到此导航，但使用它并不符合每个人的口味(并不是每个人都可能拥有 ReSharper 等插件)。

Travis G 询问了更精细的问题，例如委托(delegate)和自定义 EventArgs 声明。由于自定义 EventArgs 是类，我会将它们放在它们自己的文件中(同样，保持规则简单)。我将与使用它们的类一起声明代表。如果我发现我有很多在很多地方使用的委托(delegate)，我可能会考虑将它们全部放在一个 Delegates.cs 文件中(我有时会在 Consts.cs 文件中使用常量这样做)。

但是，其中一些肯定是主观的并且进入了软件领域 religious wars .