Yan Cui
I help clients go faster for less using serverless technologies.
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:
- 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
- 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.
- don’t forget to call Dispose() on each of the IDisposable objects in the Dispose(bool) method.
- 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()
{
Dispose(true);
GC.SuppressFinalize(this);
}
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.
Whenever you’re ready, here are 3 ways I can help you:
- Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game.
- Consulting: If you want to improve feature velocity, reduce costs, and make your systems more scalable, secure, and resilient, then let’s work together and make it happen.
- Join my FREE Community on Skool, where you can ask for help, share your success stories and hang out with me and other like-minded people without all the negativity from social media.
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.
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”.
Thanks Yan for clarification :)