MicrosoftIDisposable模式真的正確嗎？

我多次偶然發現 Microsoft 推薦的實作 IDisposable 模式的方法，它甚至在 Visual Studio 中作為燈圖示選單中的“實作介面”選項出現。它看起來像這樣：

// Override only if 'Dispose(bool disposing)' has code to free unmanaged resources
~Foo() {
    // Do not change this code.
    Dispose(calledByFinalizer: true);
}

public void Dispose() {
    // Do not change this code. 
    Dispose(calledByFinalizer: false);
    GC.SuppressFinalize(this);
}

// Put cleanup code here
protected virtual void Dispose(bool calledByFinalizer) {
    if (_disposed) return;

    if (!calledByFinalizer) { /* dispose managed objects */ }

    /* free unmanaged resources and set large fields to null */

    _disposed = true;
}

我稍微重構了建議的代碼（因為 Dispose(bool disposing) 可以打破某人的大腦，而嵌套的 if 可以打破某人的眼睛）。

但我仍然有一些疑問：

1. 假設該方法將被呼叫一次。那為什么_disposed = true放在方法的末尾而不是開頭呢？如果IDisposable.Dispose()從不同的執行緒呼叫，那么它們都可以繞過if (_disposed) return;檢查并實際執行兩次方法體。為什么不這樣做：

    if (_disposed) return;
    else _disposed = true;

2. Why is protected virtual void Dispose(bool disposing) flagged as virtual? Any derived class does not have access to the _disposed field and can easily break its behavior. We can only mark as virtual the optional part where the derived class can do anything without calling base.Dispose():

~Foo() => FreeUnmanagedResources();

public void Dispose() {
    if (_disposed) return;
    else _disposed = true;

    DisposeManagedObjects();
    FreeUnmanagedResources();

    GC.SuppressFinalize(this);
}

protected virtual void DisposeManagedObjects() { }
protected virtual void FreeUnmanagedResources() { }

uj5u.com熱心網友回復：

該模式是正確的，但假設了最壞的情況，您還必須實作終結器。也就是說，如果您需要終結器，您還必須遵循整個模式。然而...

您通常根本不需要終結器。

如果您正在為非托管資源創建原始托管包裝器，則僅需要終結器。

例如，如果您創建了一個全新的、從未見過的資料庫系統，其中與資料庫的連接是非托管資源，那么您的托管 ADO.Net DbConnection 包裝器必須實作終結器。但是，如果您為應用程式創建一個包裝器物件來管理與現有資料庫型別的連接，例如 SqlConnection、OleDbConnection、MySqlConnection 等，那么您仍然應該實作 IDisposable 但您不需要終結器。

事實證明，當您沒有終結器時，您可以安全地從記錄的 IDisposable 模式中洗掉大量代碼。

uj5u.com熱心網友回復：

1. 你不能假設它 Dispose只會被呼叫一次。在最佳實踐中，是的。在最壞的情況下，根本沒有。每種情況都不能方便地使用using陳述句。因此，與其冒險嘗試兩次清理非托管資源的代碼——這可能會變得非常糟糕，具體取決于資源的型別——而是添加了一個阻止它的標志。dispose就記住是否已經被呼叫而言，這減輕了呼叫代碼的負擔。

2. Dispose如果創建子類來實體化與基類中使用的 資源明顯不同的任何非托管資源，則必須將其宣告為虛擬以支持可能需要進行的任何單獨清理。在子類中應該在清理自己的混亂之前或之后呼叫。Disposebase.Dispose();

uj5u.com熱心網友回復：

該指南是正確的，是公認的最佳實踐，并在此處完整記錄：

這種模式的最佳實踐是這樣，除了我個人更喜歡將它包裝在一個區域塊中：

public class T : IDisposable
{
    #region IDisposable

    private bool disposedValue;

    protected virtual void Dispose(bool disposing)
    {
        if (!disposedValue)
        {
            if (disposing)
            {
                // TODO: dispose managed state (managed objects)
            }

            // TODO: free unmanaged resources (unmanaged objects) and override finalizer
            // TODO: set large fields to null
            disposedValue = true;
        }
    }

    // // TODO: override finalizer only if 'Dispose(bool disposing)' has code to free unmanaged resources
    // ~T()
    // {
    //     // Do not change this code. Put cleanup code in 'Dispose(bool disposing)' method
    //     Dispose(disposing: false);
    // }

    public void Dispose()
    {
        // Do not change this code. Put cleanup code in 'Dispose(bool disposing)' method
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }

    #endregion IDisposable
}

假設該方法將被呼叫一次。

Yes we all make this assumption, but due to programmer discretion, threading and general bad design patterns, we all assume that some nufty will break our rules. Often it is an aggressive form of direct calling dispose in a UI that fires on close, but it happens in many other scenarios too. So the pattern provided is strongly advised to cater for the scenarios where dispose IS called multiple times.

Why is protected virtual void Dispose(bool disposing) flagged as virtual? Any derived class does not have access to the _disposed field...

So the reason this method exists AND is virtual is specifically because the inheriting class does not have access to the _disposed field, the overriding implementation should call the base implementation:

base.Dispose(disposing):

If they don't then they will break the intended functionality as you say, but that is their perrogative, there are valid cases where we do specifically want to change the implementation, that is why we override.

As a UI control author this pattern is very useful and is a good level of encapsulation. In cases like yours most will end up overriding both DisposeManagedObjects and FreeUnmanagedResources. By separating these concerns you make it too hard to do any other C# Kung Fu that we might also want to do.

Your implementation is not bad, and in your use case arguably safer, but it is uniquely yours and does make some advanced tasks harder to implement or maintain because now the disposal code is split across 2 methods.

By using standard patterns, other developers and development tools are more likely to intrinsically understand and interact with your classes. This pattern has been developed over a number of years and is an aggregate of how we all used to do things in our own quirky ways.

The dispose pattern is hard to understand and until you need to override it, it is hard to see the value in this implementation. But when it goes wrong it is incredibly hard to debug, because it is often the last place we look (we always assume that it works) but it is also hard to track outside of a using(){} block.

Use the standards, those who inherit your code or run maintenance on it later will thank you.

標籤：c# idisposable

上一篇：WPFDatagrid系結欄位

下一篇：為什么程式正在運行但除錯顯示串列中沒有計數？