当前位置：文江博客话题详情

与抽象类相比，使用分部类有什么好处？

发布于 2024-07-26 05:51:59 字数 271 浏览 7 评论 0原文

我一直在阅读《Programming Microsoft® Visual C#® 2008: The Language》，以便更好地了解 C# 及其用途。我遇到了我在 ASP.Net 的 Page 类中已经遇到过的部分类。

在我看来，您似乎可以对抽象类和重写类执行部分类的操作。显然，一个团队将通过抽象方法控制界面，但无论如何你们都会相互依赖。如果目标是协作，那么源代码控制和其他工具就不能解决这个问题。

我只是错过了部分课程的要点。有人也可以提供现实世界的用途。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

若水般的淡然安静女子 2024-08-02 05:51:59

部分类与对象继承无关。部分类只是将定义类的源代码拆分为单独文件的一种方法（例如，当您在 Windows 窗体应用程序中创建新窗体时完成此操作 - 一个文件是“您的”代码，另一个文件是 .designer.cs包含 VS2008 为您管理的代码）。

回复收藏 0 原文

撧情箌佬 2024-08-02 05:51:59

一个很好的用法示例是生成部分类的一侧（例如 ORM）

回复收藏 0 原文

神妖 2024-08-02 05:51:59

部分类的好处在于您可以使用现有的类并向其添加内容。这听起来很像继承，但有很多事情是继承无法做到的，而部分类却可以做到。

下面是对为您生成的 Linq to SQL 类的一个思考。它们是自动生成的，这意味着您不应修改它们。如果没有分部类，就无法附加接口。
您可以创建一个新类并从 Linq to sql 类派生该类，但这实际上不会给您带来任何好处，因为您无法使用该接口将 linq to sql 类向上转换为您的类。

回复收藏 0 原文

温折酒 2024-08-02 05:51:59

部分类应仅限于与自动生成的代码一起使用，其中其他代码无法修改。使用它来替代继承或添加功能并不是最佳实践。

如果你有一个大班级，那就已经错了。代码应该重构为多个“真实”类而不是多个文件。一般来说，大类意味着该类做了太多事情并且违反了 SRP（单一职责原则）。

回复收藏 0 原文

三月梨花 2024-08-02 05:51:59

分部类现在在 ASP.Net 中大量使用，以允许两个源文件（基于标记的 example.aspx 和基于代码的 example.aspx.cs），以便每个源文件中定义的方法和变量对每个源文件都是可见的。
在 example.aspx

<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" />

在 example.aspx.cs 中

private object GetProperty(){ // called from aspx
    return DateTime.Now;
}

private void DoStuff(){
    ExampleControl c = exampleCntr; //exampleCntr is defined in aspx.
}

双向性质不能用抽象类重新创建。

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

<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" />

in the 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.

回复收藏 0 原文

找个人就嫁了吧 2024-08-02 05:51:59

听起来你的问题是

partial class Foo
{
  PART ONE
}
partial class Foo
{
  PART TWO
}

和

astract class FooBase
{
  PART ONE
}
partial class Foo : FooBase
{
  PART TWO
}

之间的区别虽然它们可能看起来有些相似，并且在某些情况下可以使用后一种构造来代替前者，但后一种样式至少存在两个问题：

-1- type FooBase 可能必须知道应该派生自它的具体类型的标识，并且始终使用该类型的变量，而不是 FooBase 类型。这代表了两种类型之间令人不安的紧密耦合。

-2- 如果类型 Foo 是公共的，则类型 FooBase 也必须是公共的。即使 FooBase 的所有构造函数都是内部，外部代码也可以定义从 FooBase 派生的类，而不是从 派生的类Foo; 构造此类的实例会很困难，但并非不可能。

如果派生类型可以扩展基类型的可见性，那么这些问题就不会太成问题；人们会将 FooBase 视为“一次性”标识符，它会出现两次：一次在其声明中，一次在 Foo 的声明行上，并计算出每个 FooBase 将是伪装的 Foo。事实上，FooBase 无法在没有类型转换的情况下在 this 上使用 Foo 实例成员，这可能会令人厌烦，但也可能鼓励良好的代码分区。然而，由于无法扩展基类型的可见性，因此抽象类设计似乎很糟糕。

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 FooBase would 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.

-2- If type Foo is public, type FooBase would have to also be public. Even if all the constructors of FooBase are internal, it would be possible for outside code to define classes which derived from FooBase but not Foo; constructing instances of such classes would be difficult, but not impossible.

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 FooBase as a "throwaway" identifier which would appear exactly twice: once in its declaration, and once on the declaration line for Foo, and figure that every FooBase would be a Foo in disguise. The fact that FooBase could not use Foo instance members on this without 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.

回复收藏 0 原文