Question

在重构一些C＃类时，我遇到了实现IDisposable的类。

我不假思索地为每个实现IDisposable接口的类创建了部分类文件。

例如，对于Stamper.cs - ＆gt; Stamper.cs + Stamper.Dispose.cs 其中 Stamper.cs 包含用于标记的实际逻辑和 Stamper.Dispose.cs ，其中包含dispose logic

// Stamper.cs
public partial class Stamper
{
// actual logic
}

// Stamper.Dispose.cs
public partial class Stamper: IDisposable
{
// Implement IDisposable
}

当我查看代码时，Stamper.cs现在看起来更清晰可读（现在大约52行而不是100行，其中大约50行只是一个清理处置代码）

我对此走得太远了吗？

*编辑：感谢大家的意见 - 我决定将两个文件放在一起。我遇到的问题是我在更新实际逻辑后实际上忘记更新IDisposable实现。

此外，在源代码中的方法之间导航没有太多问题。第一个原因似乎不仅仅是在我的具体案例中坚持使用一个文件解决方案的原因。

Answer 1

是的，太远了。只是在代码周围粘贴一个#Region并将其折叠以便您无法看到它有什么问题？

Answer 2

它似乎与为构造函数逻辑创建部分类一样任意。现在我必须看两个文件来讨论这个类。部分类只对设计师的东西非常值得......

Answer 3

我更希望在与保证实现IDisposable的资源相同的文件中看到dispose逻辑。虽然有一种主观性因素，但我认为它太过分了

Answer 4

我认为你的解决方案不健全。部分类通常只应用于将开发人员代码与生成器代码分开。区域通常可以更好地为代码添加结构。

Answer 5

如果您的清理程序很重，那么这是可以接受的，但并不理想。

这可能是锅炉板的好习惯，例如暴露事件，繁重的序列化方法以及您的案例内存管理。

我更喜欢部分类而不是大纲（#region）。如果必须使用部分类或代码大纲来使代码可读，这通常表明代码需要更改。撕掉类appart并且只作为最后的手段使用部分类（或区域）如果代码绝对需要用于维护该类。

在您的情况下，您可以使用一个精简包装非托管资源的类并公开一个Dispose。然后在您的其他类中，使用托管对象并在没有逻辑的情况下对其进行Dispose。

如果你的类只是一个薄的包装，那么我会说你的方法是矫枉过正的，因为类的整个要点是处置一个非托管资源。

Answer 6

有点奇怪的问题，因为它只对开发人员产生影响，完全取决于个人偏好。我只能告诉你我更喜欢什么，如果在处置部分有大量的逻辑，我会这样做。

Answer 7

就个人而言，我试图保持我的实例化/初始化逻辑和我的清理/处理逻辑并排，这是一个很好的提醒。

对于部分类，我使用它们的唯一时间是一个类非常大并且可以分类为方法组。隐藏设计师代码也很棒。

Answer 8

当有问题的代码是由计算机生成的时候，我赞成使用部分类。如果你有许多共享相似代码的类（由于各种原因必须重复，而不是被拉到自己的类中），有一些模板和程序来生成基于这些模板的代码可能是有用的。在这种情况下，模板将被视为源文件，然后生成文件作为中间对象代码。将模板生成的代码提取到部分类中似乎是完全合适的。

在vb.net中，这样的方法可能很好，允许在IDisposable对象中安全地一起处理字段声明，初始化和清理。需要适量的样板代码，但之后的字段声明非常干净。例如：

' Assuming Option Implicit on:
Dim MyThingie = RegDisposable(New DisposableThingie)
' If Implicit wasn't on:
Dim MyThingie As DisposableThingie = RegDisposable(New DisposableThingie)

RegDisposable是一个类成员，可以将新的DisposableThingie添加到该类持有的列表中。然后，类'Dispose例程将Dispose列表中的所有项。

不幸的是，在C＃中没有干净的方法可以做类似的事情，因为字段初始化器不能使用即将构造的对象（在vb.net中，字段初始化器在构造基础对象之后运行）。

我应该将Dispose逻辑分离为部分类文件吗？

8 个答案: