Question

Let’s take a look at the infamous IDisposable interface:

[ComVisible(true)]
public interface IDisposable
{
    void Dispose();
}

and a typical implementation, as recommended by MSDN (I omitted the check if current object has already been disposed):

public class Base : IDisposable
{
    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // release managed
        }
        // release unmanaged
        disposed = true;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    ~Base()
    {
        Dispose(false);
    }
}

public class Derived : Base
{
    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        if (disposing)
        {
            // release managed
        }
        // release unmanaged
        disposed = true;
    }
}

Problem is: I think this implementation is counter-intuitive. And it is also significantly different in base and derived class. Derived class is supposed to assume that base class implemented IDisposable properly and then override Dispose(bool), which is not even a part of the original interface.

I have to admit, I came up with this question because I usually ask junior programmers to implement IDisposable on a job interview. If they don’t exactly know how it’s supposed to be done, they come up with something close to this:

public class Base : IDisposable
{
    public virtual void Dispose()
    {
        // release managed and unmanaged
        GC.SuppressFinalize(this);
    }

    ~Base()
    {
        // release unmanaged
    }
}

public class Derived : Base
{
    public override void Dispose()
    {
        // release managed and unmanaged
        base.Dispose();
    }

    ~Derived()
    {
        // release unmanaged
    }
}

To me, this implementation is more clear and more consistent. Of course, the bad thing is that we have to release unmanaged resources in two different places, but the important point is that probably over 99% custom classes do not have anything unmanaged to dispose, so they won’t need a finalizer anyway. I can’t explain to a junior programmer why MSDN implementation is better because I don’t really understand it myself.

So I’m wondering, what led to such unusual design decisions (making derived class to override a different method than the one in the interface and making him think about unmanaged resources which it most probably doesn’t contain). Any thoughts on this matter?

Answer 1

So I’m wondering, what led to such unusual design decisions (making derived class to override a different method than the one in the interface and making him think about unmanaged resources which it most probably doesn’t contain). Any thoughts on this matter?

The main issue is that IDisposable was defined AFTER the framework was already designed and in existence. It’s meant to handle a situation that managed code is trying to avoid – so it’s really an edge case, if a very common one. 😉

This can be seen, btw, if you look at C++/CLI. It was designed after IDisposable, and as a result, implements IDisposable in a much more natural way (destructors [~ClassName]automatically become Dispose, and finalizers [!ClassName] are treated as finalizers).

The other issue is that IDisposable handles multiple situations. I wrote an entire blog series, walking through the different implementations that should be used when wrapping native code, encapsulating a class implementing IDisposable, and using it with factored types.

Technically, you only must implement the interface directly. The design decision to allow for a protected virtual void Dispose(bool disposing) method allows for extra flexibility that wouldn’t be easily, and safely, handled in a public interface.