See its very simple.
- If you are dealing with unmanaged resources – Implement both
Dispose
andFinalize
.Dispose
is to be called by developers to free up the resources as soon as they see it that its no longer needed for them. If they forget to callDispose
then Framework calls the finalize in its own GC cycle (usually will take its own sweet time). - If your object uses disposable objects internally – You implement
Dispose()
if you created and retained a reference to any object of a type which implementsDispose()
and which you haven’t already disposed. - If neither of the above is the case (you are NOT dealing with unmanaged resources nor your object uses disposable objects internally) – Then don’t do anything. Don’t implement
Finalize
norDispose
.
Some classic examples:
System.IO.FileStream
object manages the lock/stream handles to files. So it implements both dispose and finalize. If the developer disposes it then the other program can access it right away. If he forgets to dispose it then Framework finalize it and close the handles later in its GC cycle.
System.Text.StringBuilder
dose not have any unmanaged resource. So no dispose no finalize.
As far as the pattern is concerned what it means to
// Code to dispose the managed resources of the class
is that call the Dispose methods of any .NET objects that you have as components inside that class
And
// Code to dispose the un-managed resources of the class
Means to close the raw handles and pointers. Here is your updated code with examples
class Test : IDisposable
{
private bool isDisposed = false;
~Test()
{
Dispose(false);
}
protected void Dispose(bool disposing)
{
if (!isDisposed)
{
if (disposing)
{
// Code to dispose the managed resources of the class
internalComponent1.Dispose();
internalComponent2.Dispose();
}
// Code to dispose the un-managed resources of the class
CloseHandle(handle);
handle = IntPtr.Zero;
isDisposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
Here is an old question explaining it