The C# Dispose Pattern

The Dispose pattern is something we’ve all seen before, and it’s so tried and tested most of us (especially myself!) have been more than happy to apply without question.

Whilst reading various blogs/articles I came across some differing opinion about this well known pattern and started to question what I had taken for granted myself.

After some more research and a question on the goldmine of knowledge that is the StackOverflow I have shortlisted a few points you should consider when implementing the standard C# dispose pattern:

  1. if your object doesn’t hold any IDisposable objects or unmanaged resources (DB connection, for example) then you don’t need to implement the IDisposable or finalizer at all
  2. if your object doesn’t hold any unmanaged resources then don’t implement a finalizer, the Garbage Collector won’t attempt to finalize your object (which has a performance hit) unless you have implemented a finalizer.
  3. don’t forget to call Dispose() on each of the IDisposable objects in the Dispose(bool) method.
  4. if your object holds unmanaged resources, clean them up in the finalizer without re-writing any of the cleanup code in the Dispose(bool) method already.

So for a simple class with no unmanaged resources and a collection of IDisposable objects, your class might look something like this:

public sealed class MyClass : IDisposable
     IList<MyObject> objects;  // MyClass holds a list of objects
     private bool _disposed;   // boolean flag to stop us calling Dispose(twice)

     public void Dispose()

     private void Dispose(bool disposing)
          if (!_disposed)
               // call Dispose on each item in the list
               if (disposing)
                    foreach (var o in objects)
                         // check if MyObject implements IDisposable
                         var d = o as IDisposable();
                         if (d != null) d.Dispose();
          _disposed = true;

This is fairly similar to the standard C# Dispose pattern, the main difference being the lack of a finalizer because remember, implementing a finalizer will impact the performance of your type so don’t implement it unless you need it.


  1. Vikram Chaudhary   •  

    Great Blog and nice posts indeed..In this post you are suppressing the Finalize but there is no finalizer method implemented for the class in code snippet. Is it correct.

  2. Yan Cui   •  

    Hi Vikram, you’re right, the GC.SupressFinalize is redundant in this case (I even pointed out in point 2 in the list above the snippet that the GC won’t attempt to finalize your obj if it doesn’t have a finalizer).

    One thing I didn’t mention is that, whilst you want to optimistically dispose of unmanaged resources in the Dispose method, there’s no guarantee that the user of your class will dispose it deterministically. So, as a pessimistic fallback and safety net, you also want a Finalizer as a last-ditch attempt to ensure these resources are cleaned up when the object is finalized.

    A common pattern is to log a warning message in the Finalizer to tell the user that “finalizer was called, please ensure you dispose of ThisClass deterministically”.

Leave a Reply

Your email address will not be published.