C#接口和实现在同一个文件中-好主意?

规则简单,易于遵循。我们使用 StyleCop 内部负责监督此事。

如果将此方法与合理使用名称空间相结合,则意味着VisualStudio中的“解决方案资源管理器”视图可以轻松导航项目中的组件。注意 ReSharper gives an alternative approach 但是使用它并不是每个人都喜欢的(而且不是每个人都有像ReSharper这样的插件)。

Travis G询问了更精细的点,例如委托和自定义EventArgs声明。因为自定义EventArg是类,所以我会将它们放在它们自己的文件中(同样,保持规则的简单性)。我将向使用它们的类声明的委托。如果我发现我有很多代表在很多地方使用,我可以考虑把它们放在一个CueAccess文件中(有时我用常量,在一个SCONS.CS文件中这样做)。

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

个人

当然,如果接口有可能由多个类实现,那么我将它放在一个单独的文件中。

将接口定义和实现放在同一个文件中与单元测试无关,因为该接口无论如何都是可用的。

我通常从一个简单的接口开始,并在同一个文件上实现。随着事情的发展,当其他代码需要引用该接口时,我会将它们拆分。

我认为这是个坏主意。

保持接口和实现分离。否则,您可能会把设计搞砸。包括该文件并自动获取实现,即使您只需要接口,然后意外地(因为它很方便)使用Impl而不是接口和yay,紧密耦合。

我会坚持“一个类,一个文件”的规则。对于类,我还指接口、枚举等。

当然,这样做没有什么坏处,诸如resharper之类的工具会将实现放在代码中接口的下面。但是,它们也会让您选择将implementation移出到另一个文件中。

你是对的,它不会阻止你利用单元测试接口的好处,但是你可能想考虑将接口完全集成到另一个程序集中。这样,您就可以根据接口编程并随意交换实现,从而实现更多的分离。正如以往一样,没有正确或错误的答案,这取决于你正在努力实现什么。

我在java中用很少的方法实现小型接口。在本例中,我在接口文件中提供了一个或多个基本实现。

这样可以避免分散的小班。