在部分类中实现接口
考虑一个实现许多接口的类，使用部分类定义在单独的文件中实现每个接口是否有意义？
这是对语言功能的滥用还是我不知道的习惯用法？
Consider a class which implements a lot of interfaces, would it make sense to implement each interface in a separate file using partial class definitions?
Would this be an abuse of the language feature or is it an idiom I'm unaware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果您的类必须实现许多接口，那么这是管理源代码的合理方法，是的。您可以编辑项目文件，使其中多个项目依赖于一个“主”类文件，这使得解决方案资源管理器更易于使用。
您应该问自己是否不应该有几个较小的类，每个类都实现一个接口。有时这是一个更好的方法，有时则不是——但这个问题总是值得提出的。
If your class has to implement many interfaces, that's a reasonable way of managing the source, yes. You can edit the project file to make several of them depend on one "main" class file, which makes the Solution Explorer easier to work with.
You should ask yourself whether you shouldn't have several smaller classes each implementing a single interface though. Sometimes that will be a better approach, sometimes not - but it's always worth asking the question.
这不是我听说过的习惯用法，但听起来像是一种优雅的代码分区方式。
Not an idiom I have ever heard of, but sounds like an elegant way to partition your code.
我认为您应该问自己，为您的类实现的每个接口提供一个 .cs 文件是否会使理解代码变得更容易或更困难。你会如何命名这些文件？
虽然我在这里可能会冒险，但如果组织代码是您的目标，我想我会建议您使用令人讨厌的
#region指令。I think that you should ask yourself if having a .cs file for each interface implemented by your class would make it easier or harder to understand the code. How would you name the files?
Although I might be going out on a limb here I think I'm going to suggest that you use the much hated
#regiondirective instead if organizing the code is your goal.是的，您可以，但是与具有区域的单个文件相比，这不会给您带来任何更多优势。部分类往往很令人讨厌，因为它并不能立即明显地看出它还有另一部分，并且其他查看该类的人可能会错过它。我个人更喜欢将一切都放在一处。
You can, yes, but that won't give you any more advantages over, say, a single file with regions. Partial classes tend to be icky because it's not immediately obvious that there is another part to it, and someone else looking at the class might miss it. I personally prefer to have everything in one place.
唯一的好处是在单独的物理文件中实现各种接口。
在我看来，将类声明放在单独的物理文件中的缺点抵消了这一点。
The only benefit is to have the various interface implementations in separate physical files.
In my opinion, this is outweighed by the downside of having your class declaration located in separate physical files.
优点：可以轻松地查明类的哪个部分实现哪个接口（当您使用的工具不允许在 IDE 内轻松导航代码时，这很好）。
缺点：更容易丢失上下文，因为现在您必须浏览多个文件，
我认为随着当今 IDE 的进步，这并不重要。您可以拥有一个文件，并让该工具帮助您快速在类结构中导航。但话又说回来，无论哪种方式，工具都可以提供帮助......所以......
部分仍然适合分离生成的代码与自定义代码。
Pro: can easily pinpoint what part of a class that implement which interface (good when you are using tool that doesn't allow navigating easily through code inside the IDE).
Con: easier to lose context since now you have to navigate across multiple files
I supposed w/ the advance in IDE nowadays, it doesn't really matter. You can have a single file and let the tool help you navigate inside your class structure quickly. But then again tool can help either way... so...
Partial is still good for separating generated code vs custom code.
它与在一个分部类文件中拥有构造函数、在另一个分部类文件中拥有属性等一样有意义。也就是说
，除非有充分的理由，否则不要这样做。
It makes about as much sense as having constructors in one partial class file, properties in another partial class file, etc., etc.
i.e. Don't do it unless you have a good reason.
我认为在这种情况下，有比使用部分代码更好的方法来构建代码。 Visual Studio 中没有任何参考资料可供您参考以了解特定类有多少个部分实现，因此很容易迷失方向。
根据您真正指的“大量接口”的接口数量，您可以使用区域来分隔实现。最多有 10-15 个接口，总共需要实现 150 个功能。在那之后，事情会变得混乱，你会失去概览。
这就是您将从其他机制中受益的地方，例如继承、封装或聚合，以及服务和帮助程序类的使用。
但如果您遇到需要实现 15 个以上接口的情况，我会认真重新考虑代码的架构......
I think there are better ways of structuring your code than using partials in this case. There's no reference in Visual Studio that you can consult to see how many partial implementations there are for a particular class so it is easy to lose track.
Depending on how much interfaces you really mean with "a lot of interfaces" you can use regions to separate the implementations. That would be fine up until 10-15 interfaces with a total of, say, 150 functions to implement. After that, things will get messy and you will lose overview.
And that's where you will benefit from other mechanisms such as inheritance, encapsulation or aggregation, and the use of services and helper classes.
But I would seriously reconsider the architecture of your code if you ever come across the need to implement 15+ interfaces....