3

(very newbie questions)

i may be misunderstanding this but on MSDN i believe it says that it is good practice to implement the Dispose destructor in every class you write. should i (do you) really implement the IDisposable interface with every class i write?

also, is the proper syntax for implementing an interface to put the "Implements" keyword on the line after the "class" declaration? i put it on the same line as "class" and I got an error.

one more?: when coding the method implemented by the interface, is it mandatory to follow this syntax, as an example:

Public Sub Dispose() Implements IDisposable.Dispose

what i'm curious about in the above code, is if i need to declare the implemented method as "Implements System.IDisposable.Dispose"

abatishchev
  • 98,240
  • 88
  • 296
  • 433
400_the_cat
  • 873
  • 3
  • 16
  • 29
  • 2
    possible duplicate of [Why would a class implement IDisposable explicitly instead of implicitly?](http://stackoverflow.com/questions/3119288/why-would-a-class-implement-idisposable-explicitly-instead-of-implicitly) – Preet Sangha Jul 19 '10 at 21:49
  • 1
    Quick answers to your last two questions: `Implements` (and `Inherits`) must be on a line of its own inside class body when declaring implemented interfaces (and inherited class), and `Implements` on method declaration must be on the same line, and is required for any method implementing an interface (even if its name otherwise matches). – Pavel Minaev Jul 19 '10 at 21:50
  • 1
    Quick answer to #1: no, not all classes should implement `IDisposable`, and MSDN doesn't tell you to do that. Long answer - http://stackoverflow.com/questions/492984/what-is-the-difference-between-managed-and-native-resources-when-disposing-ne – Pavel Minaev Jul 19 '10 at 21:51
  • @Preet This is not a duplicate of that C# question. This is a VB.Net question; 400_the_cat didn't realise yet that you **have** to write `Implements blah` on the method line. Which makes it implemented explicitly and implicitly, you can just call `Dispose` or you can cast to `IDisposable` first. – MarkJ Jul 20 '10 at 10:34
  • Where in MSDN do you "believe it says that it is good practice to implement the Dispose destructor in every class you write"? – Mark Hurd Dec 01 '11 at 12:02

4 Answers4

10

You should only implement IDisposable if your class holds instances of other classes that implement IDisposable, or if it holds native resources.

For more information, see this article.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
3

No you should not. Only implement IDisposable if you are using unmanaged resources directly or have members that implement IDisposable and want to make sure their dispose method gets called when the dispose method gets called on your class.

Ben Robinson
  • 21,601
  • 5
  • 62
  • 79
  • Classes or interfaces which are designed for inheritance if it is likely that the class or interface type will be returned by a factory method that will sometimes produce objects that require cleanup. A prime example is `IEnumerator`. Even if 99.9% of classes which implement `IEnumerator` do not require cleanup, any code which can accept an arbitrary `IEnumerable` and calls `GetEnumerator` on it must, for correctness, call `Dispose` on the returned enumerator. Code which does not do so cannot legitimately accept all types of `IEnumerable`. – supercat Jun 11 '13 at 21:58
  • Note that non-generic `IEnumerator` does not implement `IDisposable` *but it should*, since any code which can accept an arbitrary `IEnumerable` can call `GetEnumerator` on it is required for correctness to check whether the returned enumerator implements `IDisposable` and dispose it if so. *This is required even though 99.9% of classes which implement `IEnumerator` don't require cleanup.* The fact that `IEnumerator` doesn't implement `IDisposable` does not relieve callers of any responsibility--it merely makes it harder for them to carry it out. – supercat Jun 11 '13 at 22:01
2

Many actions a computer might perform create the need for a counter-balancing "cleanup" action. For example, the act of opening a file creates a need to close it. The act of placing a call with a modem creates the need to disconnect it. Performing an action without performing the required counter-balancing cleanup may sometimes be harmless, but may sometimes have severe consequences in the computer or in the real world (failing to close a file before a user ejects the media may cause file corruption and data loss; failing to terminate a modem connection may cost someone many dollars in excess phone charges).

The purpose of IDisposable is provide a means by which well-behaved programs can make sure that any cleanup actions that need to be performed actually get done. Any routine which performs an operation that must be counter-balanced by cleanup should keep the information and impetus necessary to perform such cleanup until such time as it has been performed; if the routine can't perform such cleanup before returning to the caller, it should either (1) provide the information to the caller, and be documented as requiring the caller to use that information to perform the cleanup, or (2) keep the necessary information in one or more fields, and implement IDisposable; when IDisposable.Dispose is called, the object should use the saved information to perform the cleanup.

Note that IDisposable only works cleanly if any object that requests the creation of an IDisposable object accepts and honors the responsibility of making sure that the object's IDisposable.Dispose method will be called sometime. The system does provide a "backup" means, called finalization, which objects can use to ensure that they get a chance to perform their cleanup. Essentially, an object registers a request with the system that says "Let me know if I've been abandoned". If the system detects that an object has been abandoned, it will try to give the object a chance to perform any necessary cleanup. Note the system may take awhile to notice that an object has been abandoned, and for various reasons the notifications may not always happen. It is almost always much better to call IDisposable.Dispose on objects before they are abandoned, than to rely upon the "last chance" finalization mechanism.

supercat
  • 77,689
  • 9
  • 166
  • 211
0

The .Net framework has a garbage collector and for the most part manages allocation and release of memory for you (when creating a new object). However you also need to manage un-managed resources (I also seen being refereed to as native resources). So now the garbage collector is not good enough and you have to manage memory using the IDisposable interface. A good example is creating the DataAccesslayer where you handle database connection and use the IDisposable interface

check this out to see how to implement iDisposable interface: https://msdn.microsoft.com/en-us/library/498928w2%28v=vs.110%29.aspx

Sha Par
  • 93
  • 2
  • 5