Menu
How can I determine if I should extend one of my interfaces with IDisposable or implement IDisposable on a class that implements my interface?
I have an interface that does not need to dispose of any external resources, except for one particular implementation. My options seem to be:
1) Implement IDisposable on the interface requiring all of the implementations to implement Dispose, even if only an empty method.
-or-
2) Implement IDisposable on only the classes that have resources needing to be disposed. This will cause problems with "using" because my object is created from a factory and therefore all upstream code works against the interface. Since the interface is not bound to IDisposable, "using" does not see the Dispose method. However, I could cast the factory result to the implementation; however, that then makes the consumer aware of the implementation, defeating the purpose of interfaces.
Any ideas as to best practices?
904
in a class, you should implement IDisposable and overwrite the Dispose method to allow you to control when the memory is freed. If not, this responsibility is left to the garbage collector to free the memory when the object containing the unmanaged resources is finalized.
If your class creates unmanaged resources, then you can implement IDisposable so that these resources will be cleaned up properly when the object is disposed of. You override Dispose and release them there.
Typically, types that use unmanaged resources implement the IDisposable or IAsyncDisposable interface to allow the unmanaged resources to be reclaimed. When you finish using an object that implements IDisposable, you call the object's Dispose or DisposeAsync implementation to explicitly perform cleanup.
IDisposable is an interface that contains a single method, Dispose(), for releasing unmanaged resources, like files, streams, database connections and so on.
If you expect callers to only be able to interact with the interface, and never the implementation, then you want to have the interface extend IDisposable. If not, they'll need to check if the value is IDisposable anyway to see if it needs to be disposed.
If the object responsible for disposing of the object knows of the concrete implementation, and it is only ever objects that are given references to it (but aren't responsible for disposing of it) that use the interface, then consider the second option.
A good example of the first option is IEnumerator. Many IEnumerator objects don't need to do anything when they're disposed, but some do, and so the interface extends IDisposable because the object responsible for the creation/lifecycle of that object will (or should) never have knowledge of the underlying implementation.
An example of the second would be something like IComparer many objects that need to be compared are disposable, but the sections of code using an object through the interface aren't responsible for it's creation/lifecycle, so it needs no knowledge of whether or not that type is disposable.
156
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
