接口属于自己的文件
按照经验，我通常将类放在自己的文件中。 Visual Studio似乎鼓励这一点，但接口方面的内容是什么？
例如
我有Class Foo实现接口Bar
public interface IBar { } public class Foo : IBar { } 将这些组合在同一个文件中似乎很自然，直到另一个类实现接口，但是将文件专用于2行代码似乎过多但正确。
什么是合适的？
我会把它们分成2个文件。 当他们不在自己的文件中时，我经常发现课程开始变得无法管理。
想象一下，试图在名为IBar.cs的文件中找到类Foo，反之亦然。
由于接口的目的是为（可能）多个实现类定义“契约”，我会说将接口定义放在自己的文件中更有意义。 即如果你也想让Baz实现Foo会发生什么？
根据具体情况，我将每个接口拆分为自己的文件，或者另外还有一个Interfaces.cs文件，我将给定命名空间中的接口组合在一起。
我永远不会将接口放在同一个.cs文件中作为实现它的类。
我只有两种情况，我发现自己将多个顶级类型放在一个文件中：
- 如果您要定义多个委托类型。 每个只是一个声明，所以有一个
Delegates.cs文件是有道理的。 -
有时，声明一大堆自动生成的部分类型实现了一堆接口是有意义的。 同样，每种类型一行：
// Actualy code is in the autogenerated file public partial class Foo : ICommon {}
除此之外，我每个顶级类型使用一个文件，用于接口，类和枚举。
你当然应该把界面放在它自己的文件中。 您甚至可以考虑将接口放在它自己的类库中。 如果接口将由两个不同库中的两个不同类使用，则将接口放在第三个库中是有意义的，因此如果要将接口添加到新项目，则不必包含任何特定实现。 在第三个库中，您还可以放置使用实现接口的类的类（例如，public void Cook（IBar x））。
是的，拥有一个接口意味着您将拥有多个具有相同方法和属性定义的类。 暂时将它放在一个文件中很方便，因为它很容易修改而无需更改文件。 随着时间的推移，你会和其他课程一起使用它，如果你必须在路上做出改变，你将不得不寻找并啄正确的文件。
我总是把它们放在单独的文件中。 每个文件有多个类型只会分散IMO的注意力。 我可能会为他们创建一个文件夹“Interfaces”。 另外，我认为你不应该像实际的实现那样经常修改它们，所以将它们分开至少可以促进这一点。
在封装方面，每个对象（无论是类还是接口）都应该在自己的文件中。 即使接口只包含一个抽象方法，它在不同文件中的事实也允许更好的组织和更好的封装。 您可以将这些不同的接口存储在文件夹中，为其提供适当的命名空间，从而提供更清晰的解决方案。