How to deal with a class than encapsulates a disposible instance?

Question

interface IMyInterace
{
void Open();
object Read();
void Close();
}

class MyImplementation : IMyInterface
{
public void Open() { /* instantiates disposible class */ }
//...
public void Close() { /* calls .Dispose(); */ }

}

Is there a good way to deal with this type of situation to ensure that disposible instances inside the class get called? (There is no signal to callers that they must call 'Close' except in documentation.) Implementations of IMyInterface do not necessarily encapsulate IDisposible instances and are closed and reopened repeatedly throughout the application's lifetime.

I'm thinking of doing this:

• Implement IDisposible in MyImplementation.
• Set Dispose() to call Close().
• Add a call to Close() or Dispose() to the begining of Open to ensure previous call was closed.

Users of IMyInterface do not know what implementation they are using, so I'm not sure how much value making MyImplementation disposible has, and again, not all implementations will encapsulate IDisposibles.

Answer 1

In addition to the answers already here:

If this class is (often/sometimes) used through the interface alone I would advice to inherit IMyInterace from IDisposable.

That will let your users use these objects in a consistent manner. The drawback is of course that you may need to add (dummy) Dispose methods to classes that don't actually need it. But the benefit is in consistency and flexibility: What if a class changes in the future so that it does need a Dispose() ?

A minimal approach:

interface IMyInterace : IDisposable { }

sealed class MyImplementation : IMyInterface 
{   
   public void Open() { /* instantiates disposible class */ }

   public void Close() { /* calls _myField.Dispose(); */ }

   public void Dispose() { Close(); }  // only use this short form in a sealed class

}

Answer 2

The standard way to handle this is to simply have MyImplementation implement IDisposable.

Answer 3

As John mentioned, your first bullet point is right on.

Sometimes a Close() method is functionally synonymous with Dispose(), and exists to maintain semantic consistency with an abstraction. That is, to complement a Open() method. Other times, Close() will allow you to re-open, but Dispose() should not. Your second bullet-point is therefore fine, as well.

Bullet point 3 is not necessarily applicable, because a disposed object should not be reused. If you need to call Open() again, you need to use a new instance. In fact, the Open() method should throw an ObjectDisposedException once Dispose() have been called (by checking a private disposed boolean flag). If you want the object to support re-opening after close, you might consider using Debug.Assert() and/or throwing an exception if Open() is called without Close(). This will help to prevent sloppy management of these instances.

Be sure to follow the full disposable pattern, which is more involved than simply implementing the interface:

bool disposed;

public void Dispose() // don't make virtual!
{
    Dispose(true);
    GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
    if(!disposed)
    {
        if(disposing) 
        {
            // dispose of managed resources here, for example:
            // if(resource != null) { resource.Dispose(); } 
        }
    }

    // dispose of unmanaged resources here 

    disposed = true;
}