考虑一个实现了大量接口的类，使用partial class定义在单独的文件中实现每个接口是否有意义？
这是滥用语言功能还是我不知道的成语？
答案 0 :(得分：12)
如果您的类有来实现许多接口，那么这是管理源的合理方法，是的。您可以编辑项目文件，使其中的几个依赖于一个“主”类文件，这使得解决方案资源管理器更易于使用。
你应该问问自己，你是否应该有几个较小的类，每个类都实现一个接口。有时这将是一种更好的方法，有时候不是 - 但总是值得提问。
答案 1 :(得分：4)
这不是我听过的习惯用语，但听起来像是一种优雅的分区代码方式。
答案 2 :(得分：3)
我认为你应该问问自己，为你的类实现的每个接口都有一个.cs文件会让你更容易理解代码。你怎么命名文件？
虽然我可能会在这里走出困境，但我认为如果组织代码是您的目标，我会建议您使用非常讨厌的#region指令。
答案 3 :(得分：2)
你可以，是的，但是，与单个带有区域的文件相比，这不会给你带来任何好处。部分类往往是icky，因为它不是很明显，还有另一部分，而其他人看着这个类可能会错过它。我个人更喜欢把所有东西放在一个地方。
答案 4 :(得分：1)
唯一的好处是将各种接口实现放在不同的物理文件中。
在我看来，将您的类声明放在单独的物理文件中的缺点已经超过了这一点。
答案 5 :(得分：1)
Pro：可以轻松查明实现哪个接口的类的哪个部分（当您使用的工具不允许轻松浏览IDE中的代码时）。
Con：因为现在你必须浏览多个文件，所以更容易丢失上下文
我认为现在有了IDE的进步，这并不重要。您可以拥有一个文件，并让该工具帮助您快速在类结构中导航。但是再一次工具可以帮助两种方式......所以...
部分仍然可以将生成的代码与自定义代码分开。
答案 6 :(得分：1)
它与在一个部分类文件中具有构造函数，在另一个部分类文件中具有属性等等一样有意义。
即。除非你有充分的理由，否则不要这样做。
答案 7 :(得分：0)
我认为构建代码的更好的方式比在这种情况下使用partial更好。在Visual Studio中没有参考，您可以参考以查看特定类的部分实现有多少，因此很容易失去跟踪。
取决于你真正意味着多少接口＆＃34;很多接口＆＃34;您可以使用区域来分隔实施。这将是很好的，直到10-15个接口，总共150个功能实现。在那之后，事情会变得混乱，你将失去概述。 在那里，您将从其他机制中受益，例如继承，封装或聚合，以及服务和帮助程序类的使用。
但如果您遇到需要实现15个以上接口的话，我会认真地重新考虑代码的架构 ....