C# 最佳实践:何时不/不使用分部类

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/351272/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-04 00:09:56  来源:igfitidea点击:

Best Practices: When not/to use partial classes

c#coding-stylepartial-classes

提问by Wayne Bloss

I have been using the partial class modifier for some time in order to put helper classes in their own file.

我一直在使用部分类修饰符来将辅助类放在自己的文件中。

Today we got a new guy and he said that the last team he worked with didn't allow partial classes for this because modifying a helper class that is in a separate file would cause the main partial class file to get out of whack with the changes. Also, they were only allowed to put a helper classes inside of the main class as the last resort so that everything remained decoupled.

今天我们有一个新人,他说他合作的最后一个团队不允许为此使用分部类,因为修改单独文件中的帮助类会导致主要分部类文件因更改而失控. 此外,他们只允许在主类中放置一个辅助类作为最后的手段,以便一切保持解耦。

What do you think? Is there any problem using partial classes like this or does it boil down to preference?

你怎么认为?使用这样的部分类有什么问题还是归结为偏好?

For instance, I usually have something like this:

例如,我通常有这样的事情:

  • MainClass.cs
  • MainClass.Helper1.cs
  • MainClass.Helper2.cs
  • 主类.cs
  • 主类.Helper1.cs
  • 主类.Helper2.cs

...

...

// Inside of MainClass.cs I have code like this:

public abstract partial class MainClass
{
    // ...
}

// Then in the MainClass.Helper1.cs I have:

partial class MainClass
{
   private class Helper1
   {
       // ...
   }
}

采纳答案by Marc Gravell

Partial classes are primarilyfor code-generator usage, such as designers - but I use the approach you have cited - in particular when an object implements multiple (non-trivial) interfaces, I find it useful to break it up 1 file per interface implementation. I also commonly have a file for the static methods, which are usually different enough from instance methods to warrant separation.

部分类主要用于代码生成器,例如设计器 - 但我使用您引用的方法 - 特别是当一个对象实现多个(非平凡)接口时,我发现将每个接口实现分解为 1 个文件很有用. 我通常也有一个静态方法的文件,它们通常与实例方法有足够的不同以保证分离。

回答by Nathan W

I'm not a very big fan of partial classes and don't use them myself.

我不是部分类的忠实粉丝,我自己也不使用它们。

The one time I do find them helpful and OK to use however is when you want to add something to the LINQ to SQL designer code, but apart from that I find if you are spreading the code out into different files just for the sake of it, it can make it very hard to read and manage.

有一次我确实发现它们很有用并且可以使用,但是当您想向 LINQ to SQL 设计器代码添加一些内容时,但除此之外,我发现您是否只是为了它而将代码分散到不同的文件中,它会使阅读和管理变得非常困难。

Maybe if you have classes split into many files maybe your classes are doing to much... just a thought:)

也许如果您将类拆分为许多文件,那么您的类可能做了很多......只是一个想法:)

回答by Patrik Svensson

Personally I can't see anything wrong with using partial classes like this, but that's just my own opinion. The only thing that might seem like "bad practice" is to name your classes "Helper1" and "Helper2" (but that might be an example only for clarification).

我个人认为使用这样的部分类没有任何问题,但这只是我自己的意见。唯一可能看起来像“不好的做法”的是将您的类命名为“Helper1”和“Helper2”(但这可能只是一个示例,仅供说明)。

If you're using partial classes like this, check out the (free) addin vsCommands(for Visual Studio 2008) that makes it really easy to group files in the solution explorer (just like designer files) without editing the project file.

如果您正在使用这样的部分类,请查看(免费)插件vsCommands(适用于 Visual Studio 2008),它可以非常轻松地在解决方案资源管理器中对文件进行分组(就像设计器文件一样),而无需编辑项目文件。

回答by Zachary Yates

Short answer: If all of the classes are your code, you don't really need helper classes, which invalidates your need for partials.

简短的回答:如果所有的类都是你的代码,你真的不需要帮助类,这使你对部分的需求无效。

Long answer: I'm not sure that there is anything that says your practice is explicitly wrong. From my experience, if you've got several different files that compose the entire class, you do need a good reason to do so, because:

长答案:我不确定是否有任何内容表明您的做法是明确错误的。根据我的经验,如果你有几个不同的文件组成整个类,你确实需要一个很好的理由这样做,因为:

  1. Partial classes reduce readability somewhat
  2. If your classes have multiple helper classes within them, it may be a symptom of a poor design, I don't think I've ever run into a situation where I was forced to write helper classes for classes I created.
  1. 部分类在一定程度上降低了可读性
  2. 如果您的类中有多个辅助类,这可能是设计不佳的征兆,我认为我从未遇到过被迫为我创建的类编写辅助类的情况。

However, I think the best reason to use partial classes is code generation, where you want to be able to re-generate a file without losing custom work.

但是,我认为使用部分类的最佳理由是代码生成,您希望能够在不丢失自定义工作的情况下重新生成文件。

回答by Andrew Kennan

I think that if the nested classes are large enough that you feel the need to split them into their own files they should probably not be nested classes. Make them internal members of the same namespace as MainClass instead.

我认为,如果嵌套类足够大,您觉得需要将它们拆分为自己的文件,则它们可能不应该是嵌套类。使它们成为与 MainClass 相同命名空间的内部成员。

Partial classes really only exist to support code generators and using them to break programmer written code into manageable chunks is an indicator of poor design.

部分类实际上只是为了支持代码生成器而存在,使用它们将程序员编写的代码分解成可管理的块是设计不佳的一个指标。

See this articlefor a hilarious example of what not to do with partial classes.

请参阅这篇文章,了解不要使用部分类做什么的有趣示例。

回答by Neil

I've actually done the same thing. As has been stated, there is a slight readability hit on deciphering the partial classes.

我其实也做过同样的事情。如前所述,在破译部分类时有轻微的可读性。

Decoupling is the main reason I likethis solution. A private inner class is far less coupled to everything else, because nothing else can see it or use it (although they may be talking about the potential for it to access the parent class's private data, which would usually be a bad idea).

解耦是我喜欢这个解决方案的主要原因。私有内部类与其他所有东西的耦合要少得多,因为没有其他东西可以看到或使用它(尽管他们可能在谈论它访问父类私有数据的潜力,这通常是一个坏主意)。

回答by dkretz

I think it's good to remember that your tool's default behavior is to create a low-level form of Coupling Not Cohesion; and view it skeptically, and override it unless it makes sense for some of the specific reasons listed above. But it's not good default behavior.

我认为记住您的工具的默认行为是创建低级形式的 Coupling Not Cohesion 很好;并怀疑地查看它,并覆盖它,除非由于上面列出的某些特定原因而有意义。但这不是很好的默认行为。

回答by Samnang

Most of times I use partial class only with code generation, so I can extend my classes' behaviors on separated classes that they need some customization and don't include in code generation.

大多数情况下,我只将部分类用于代码生成,因此我可以在需要一些自定义且不包含在代码生成中的分离类上扩展我的类的行为。

回答by Pitambar

In my experience, there no difference between noramal class and partial class.If your design requires large stucture of class or implementing more interfaces then go for partial class. Any how both are same.

根据我的经验,普通类和部分类之间没有区别。如果您的设计需要大型类结构或实现更多接口,那么请选择部分类。两者都是一样的。

回答by Choco Smith

I usually never use partial classes for similar reasons stated above.

出于上述类似的原因,我通常从不使用部分类。

But! While not frequent I have sometimes found that extensively unit testing a class (usually external classes) leads to giant unit test classes. Splitting the unit test class into partial classes makes it a bit easier on the eyes and to understand.

但!虽然不常见,但我有时发现对类(通常是外部类)进行广泛的单元测试会导致巨大的单元测试类。将单元测试类拆分为部分类使其更容易理解和理解。

Similar to the grouping idea when inheriting from multiple interfaces, unit test can be grouped for functions.

类似于从多个接口继承时的分组思想,单元测试可以对功能进行分组。