Why would a class implement IDisposable explicitly instead of implicitly?
I was using the FtpWebResponse class and didn't see a Dispose method. It turns out that the class implements IDisposable, but does so explicitly so that you must first cast your instance to IDisposable before calling Dispose:
// response is an instance of FtpWebResposne
((IDisposable) response).Dispose();
Why would the designer of a class such as this one choose to implement IDisposable explicitly? As Anthony Pegram says, doing things this way masks the fact that the object should be disposed for the average developer who is not consulting the documentation every time he/she uses a class.
This is normally done if the class has a Close method that is the exact same as Dispose . The original Dispose is hidden in an explicit implementation so that the exact same method doesn't have two names.
It's officially recommended here:
Do implement a Close method for cleanup purposes if such terminology is standard, for example as with a file or socket. When doing so, it is recommended that you make the Close implementation identical to Dispose...
Consider implementing interface members explicitly to hide a member and add an equivalent member with a better name.
Occasionally a domain-specific name is more appropriate than Dispose. For example, a file encapsulation might want to use the method name Close. In this case, implement Dispose privately and create a public Close method that calls Dispose.
(PS I disagree with this convention.)
It's a little weird looking to me too. For what it's worth: the base class (WebResponse) implements a Close() method. Reflector shows that WebResponse's Dispose() method just calls Close() and an Internal OnDispose virtual that does nothing.
I have to confess that it smells a little to me, but I bet that they explicitly implemented IDisposable so that there would not be confusion in Intellisense between calling Close() or Dispose().
链接地址: http://www.djcxy.com/p/54514.html