re: Should Interfaces Derive from IDisposable?

Rory Primrose — Fri, 13 Mar 2009 21:28:41 GMT

I agree. IDisposable is only relevant to an instance of a class and doesn't mean anything for an interface. To place it on an interface would be an unnecessary constraint.

As a side note, you may be interested in this:

<a href="http://www.neovolve.com/post/2008/07/03/reflection-pop-quiz-does-interface-inheritance-exist.aspx'>http://www.neovolve.com/post/2008/07/03/reflection-pop-quiz-does-interface-inheritance-exist.aspx">http://www.neovolve.com/post/2008/07/03/reflection-pop-quiz-does-interface-inheritance-exist.aspx</a>

re: Should Interfaces Derive from IDisposable?

Joe Albahari — Sat, 14 Mar 2009 03:19:47 GMT

This reasoning might also apply to abstract classes such as Stream - a MemoryStream, for example, doesn't need disposing.

The counterargument is that manual disposal is clumsy - and in most cases requires a try/finally block. It's also less discoverable - consumers might not realize that they have to dispose an object if working via interfaces.

For interfaces such as IDbConnection and IDataReader - whose implementations always need IDisposable, it would be awkward having to deal with a cast and try/finally block whenever it was used. The following code is the simplest and most natural:

using (IDataReader reader = myIDbCommand.ExecuteReader())

{

...

}

Same deal with streams.

So maybe it depends on the particular situation.