Michael argues that the guideline we have around using a customized name for the Dispose method is a bad idea because it adds developer confusion.   This is a reasonable argument, and one that heavy hitters such as Jeffrey Richter buy into as well, so it is worth some careful thought.


I think the easiest way to understand this issue is via an example, let’s take a look at the System.IO.FileStream class… currently it is defined as:


public class FileStream: Stream, IDisposable {

    //all the normal methods

   void IDisposable.Dispose () { //explicitly implemented

       //close the file handle, etc


  public void Close () {





Notice that the Dispose method is not public… it is explicitly implemented on the class.  This means that the Dispose method can only be called directly when an instance of the FileStream class is cast to IDisposable.  We also provide Close() method that is publicly accessible off the FileStream class.

      FileStream s = new FileStream (…);

      s.Close();// works great

      s.Dispose(); //compile error

      ((IDisposable) s).Dispose(); //works great


We use this combination in order to:

1.       Meet the time honored expectation that file related things are “Closed” not “Disposed”, etc.  We did not want to force every developer to learn the Dispose is just “our name for Close”…

2.       We wanted to enable FileStream to plug into generic mechanisms for ensure deterministic finalization such as C#’s using statement. 

3.       We wanted only one way to Close\Dispose a file in explicitly in code.  


The Jeff and Michael camp would rather see us have only the Dispose method (if my understanding is right).  While that meets goals 2 and 3 outlined above, I believe the fact that it fails 1 is a significant enough problem to warrant the additional implementation complexity of our current story.  I say implementation complexity because I don’t believe that many users actually find any additional complexity with this design.  They just use Close() and\or C#’s using support and have no problems.


That said, I have sympathy for the argument and, like most features explicit implementation can be abused.  As such we are working on a guideline right now to help clear that up.  Suggestions always welcome!