c#-DRY IDisposable模式
作者:互联网
我的很多课程都重复以下代码以实现IDisposable.这似乎违反了DRY(请勿重复自己)原则.我可以通过创建AbstractDisposable基类来避免一些工作,但是这似乎不合适/如果我需要扩展其他现有对象(假设那些对象本身不是一次性的)是行不通的.
另一个选择是使用模板/元语言,我可以为每个类指定托管和非托管资源的列表,并在构建项目时自动生成通用的Dispose Pattern-但到目前为止,我还没有使用元语言/对于这种常见情况,这似乎是极端的.
public class SomeDisposableClass : IDisposable
{
IDisposable _something; //a managed resource (unique to this class / here for illustration)
/* ... loads of code unique to this class ... */
#region Dispose Pattern
private bool _disposed = false;
~SomeDisposableClass()
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
// Check to see if Dispose has already been called.
if (!this._disposed)
{
if (disposing)
{
// Dispose managed resources.
if (this._something!=null) this._something.Dispose(); //(unique to this class / here for illustration)
}
// Clean up any unmanaged resources
this._disposed = true;
}
}
#endregion
}
在不违反DRY原理的情况下,有没有很好的方法来实现合适的Dispose模式?
解决方法:
我尽力避免IDisposable.问题是它散布在整个代码库中.如果一个班级有一个可抛弃的成员,那么该班级也需要实现IDisposable等.
此外,当我们谈论类型层次结构时,IDisposable存在问题.
常见的情况是,如果您认为派生类需要释放资源,则将IDisposable粘贴到基类甚至接口上.但是,在大多数情况下,这仅是一个假设,并且是否需要清理资源实际上取决于实际的实现,这使接口成为一个泄漏的抽象.
如果类确实需要该接口,最好只实现该接口.
但这有其自身的问题:
某个接口的使用者应该如何知道他得到的具体实例(例如作为构造函数参数)需要处理?他将必须明确检查它.从根本上说,他将必须为他处理的每种非密封类型的每个实例执行此操作.
这些只是两个示例,它们表明您最好以某种方式设计类,从而使它们不需要实现IDisposable.
但是,如果确实需要实现此接口,则应遵循this CodeProject article描述的“一次性设计模式”.
它基本上将您的类型分为两个级别:
> 0级:0级的类仅包含非托管资源,不包含托管资源.这些类需要大多数通常的默认IDisposable模式,尽管您不必实现处理托管资源的部分.
>级别1:级别1的类仅包含级别0和1的托管资源.这些类仅需要IDisposable的简化实现,因为它们不包含非托管资源.该实现基本上只是在其0级和1级成员及其基类上调用Dispose.
标签:idisposable,dry,c,design-patterns 来源: https://codeday.me/bug/20191030/1968453.html