C# 与抽象类相比，使用分部类有什么好处？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1057851/
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
What are the benefits to using a partial class as opposed to an abstract one?
提问by uriDium
I have been reading Programming Microsoft? Visual C#? 2008: The Language to get a better understanding of C# and what can be done with it. I came across partial classes which I had already encountered from ASP.Net's Page class.
我一直在读微软编程？视觉 C#？2008 年：更好地理解 C# 以及可以用它做什么的语言。我遇到了我已经从 ASP.Net 的 Page 类中遇到的部分类。
To me it seems that you can do what partial classes do with an abstract class and an overridden one. Obviously one team will be in control of the interface via the abstract methods but you would be relying on each other anyway. And if the goal is collaboration then isn't that what source control and other tools solve.
对我来说，您似乎可以对抽象类和被覆盖的类做部分类所做的事情。显然，一个团队将通过抽象方法控制接口，但无论如何你们都会相互依赖。如果目标是协作，那么源代码控制和其他工具就不能解决这个问题。
I am just missing the point to a partial class. Also could someone provide a real world use.
我只是错过了部分课程的重点。也有人可以提供现实世界的用途。
采纳答案by Thorsten Dittmar
Partial classes have nothing to do with object inheritance. Partial classes are just a way of splitting the source code that defines a class into separate files (this is for example done when you create a new form in your Windows Forms application - one file is "your" code, another file .designer.cs contains the code that VS2008 manages for you).
部分类与对象继承无关。分部类只是将定义类的源代码拆分为单独文件的一种方式（例如，当您在 Windows 窗体应用程序中创建新表单时会这样做 - 一个文件是“您的”代码，另一个文件是 .designer.cs包含 VS2008 为您管理的代码）。
回答by Mitch Wheat
A good usage example is when one side of the partial class is generated (such as an ORM)
一个很好的用法示例是生成分部类的一侧（例如 ORM）
回答by Perica Zivkovic
Purpose of partial classes is to allow a class's definition to span across multiple files. This can allow better maintainability and separation of your code.
部分类的目的是允许类的定义跨越多个文件。这可以允许更好的可维护性和代码分离。
回答by Carra
We use partial classes to split up our larger classes. That way it's easier to check out a part of the code with Sourcesafe. This limits the cases where four developers need to access the same file.
我们使用部分类来拆分更大的类。这样就可以更轻松地使用 Sourcesafe 检出部分代码。这限制了四个开发人员需要访问同一个文件的情况。
回答by kemiller2002
The great thing about a partial class is that you can take an existing class and add on to it. Now this sounds a lot like inheritance, but there are a lot of things that inheritance can't do that partial classes will.
部分类的好处在于您可以使用现有的类并添加到它。现在这听起来很像继承，但是有很多事情是继承不能做的，而部分类却能做到。
Here's one think about the Linq to SQL classes generated for you. They are autogenerated meaning you shouldn't modify them. Without a partial class, you can't attach an interface. You could create a new class and derive that from the Linq to sql class, but that really doesn't get you anything because you can't upcast the linq to sql class to your class with the interface.
这是为您生成的 Linq to SQL 类的一个想法。它们是自动生成的，这意味着您不应修改它们。没有分部类，就不能附加接口。您可以创建一个新类并从 Linq to sql 类派生它，但这实际上并没有给您带来任何好处，因为您无法使用接口将 linq to sql 类向上转换为您的类。
回答by David Waters
Partial class are now used heavily in ASP.Net to allow two source files the mark-up based example.aspx and the code based example.aspx.cs so that methods and variable defined in each are visible to each. in the example.aspx
部分类现在在 ASP.Net 中大量使用，以允许基于标记的 example.aspx 和基于代码的 example.aspx.cs 的两个源文件，以便每个文件中定义的方法和变量对每个文件都是可见的。在example.aspx
<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" />
in the example.aspx.cs
在example.aspx.cs
private object GetProperty(){ // called from aspx
return DateTime.Now;
}
private void DoStuff(){
ExampleControl c = exampleCntr; //exampleCntr is defined in aspx.
}
The bi-directional nature of this cannot be recreated with abstract classes.
这种双向性质无法用抽象类重新创建。
回答by vasya10
Partial classes should be restricted to using with auto-generated code, where the other code cannot be modified. Using it as a substitute for inheritance or adding functionality are not best practices.
部分类应仅限于与自动生成的代码一起使用，其他代码不能修改。使用它代替继承或添加功能不是最佳实践。
If you have a large class, its already wrong. Code should be refactored into multiple "real" classes instead of multiple files. Large classes in general signifies the class is doing too many things and violates SRP (Single Responsibility Principle).
如果你有一个大班，那已经是错误的了。代码应该被重构为多个“真正的”类而不是多个文件。大类通常意味着该类做的事情太多并且违反了 SRP（单一职责原则）。
回答by supercat
It sounds like your question is what the difference is between
听起来您的问题是两者之间的区别
partial class Foo
{
PART ONE
}
partial class Foo
{
PART TWO
}
and
和
astract class FooBase
{
PART ONE
}
partial class Foo : FooBase
{
PART TWO
}
While they may appear somewhat similar, and in some cases the latter construct could be used in place of the former, there are at least two problems with the latter style:
虽然它们可能看起来有些相似，并且在某些情况下可以使用后一种结构代替前者，但后一种风格至少存在两个问题：
-1- The type FooBasewould likely have to know the identity of the concrete type which was supposed to derive from it, and always use variables of that type, rather than of type FooBase. That represents an uncomfortably-close coupling between the two types.
-1- 该类型FooBase可能必须知道应该从中派生的具体类型的身份，并且始终使用该类型的变量，而不是 type 的变量FooBase。这代表了两种类型之间令人不安的紧密耦合。
-2- If type Foois public, type FooBasewould have to also be public. Even if all the constructors of FooBaseare internal, it would be possible for outside code to define classes which derived from FooBasebut not Foo; constructing instances of such classes would be difficult, but not impossible.
-2- 如果类型Foo是公共的，类型FooBase也必须是公共的。即使所有的构造FooBase是internal，将有可能对于外部码以限定从派生的类FooBase而不是Foo; 构建此类类的实例会很困难，但并非不可能。
If it were possible for a derived type to expand the visibility of a base type, these issues wouldn't be overly problematical; one would regard FooBaseas a "throwaway" identifier which would appear exactly twice: once in its declaration, and once on the declaration line for Foo, and figure that every FooBasewould be a Fooin disguise. The fact that FooBasecould not use Fooinstance members on thiswithout a typecast could be irksome, but could also encourage a good partitioning of code. Since it isn't possible to expand the visibility of a base type, however, the abstract-class design seems icky.
如果派生类型可以扩展基类型的可见性，这些问题就不会太成问题；人们会认为它FooBase是一个“一次性”标识符，它恰好出现两次：一次在其声明中，一次在声明行上 for Foo，并且认为每个FooBase都是Foo伪装的。FooBase不能Foo在this没有类型转换的情况下使用实例成员的事实可能令人讨厌，但也可以鼓励良好的代码分区。然而，由于无法扩展基类型的可见性，抽象类设计似乎很棘手。
