I've never done this myself, but I believe this component stuff and the suppressing garbage collection all has to do with unmanaged resources. It also adds a layer that ensures that Dispose() is not called more than once. If you read through the MSDN notes of why they're doing all of this, I'm sure there are valid reasons. However, in my opinion, if you're defining something with only simple managed types, then you should be safe doing it the short way - dispose only what needs to be specially disposed, and let garbage collection handle the rest of it.
The "disposed" field that lets you ensure that it's only actually disposed once is probably a good idea - you may want to at least consider using that. In theory, no one will ever call Dispose() more than once, assuming they're using a "using" block, but you can't guarantee that other developers in the future won't do something weird. On Mar 19, 8:05 am, Alon K <[email protected]> wrote: > And I forgot to add. The code I posted below also adds a 'components' > instance, adding to the complexity of using Dispose. What is it and > why do I have to add it, what does it do? > > On Mar 19, 11:00 am, Alon K <[email protected]> wrote: > > > So from what I understood - it isn't really necessary to implement a > > long winded Dispose() definition like I found in most examples which > > clears every member variable/class, I can just implement what I need > > done in addition (for example you implemented "Save();") and the > > garbage collection will take care of everything else (such as > > releasing resources for the variable Success). > > > This code snippet is from MSDN and is different from what you are > > using. Can you explain the differences and why one would choose to use > > this approach (or conversly your approach). This is the type of code I > > see in almost every example online and what got me confused in the > > first place. > > > public void Dispose() > > { > > Dispose(true); > > GC.SuppressFinalize(this); > > } > > > private void Dispose(bool disposing) > > { > > if(!this.disposed) > > { > > if(disposing) > > { > > component.Dispose(); > > } > > > // Do Stuff > > > disposed = true; > > } > > } > > > While using your example would just be: > > > public void Dispose() > > { > > // Do Stuff > > } > > > On Mar 19, 10:22 am, Joe Enos <[email protected]> wrote: > > > > IDisposible makes it easy to do what you're doing. The whole point of > > > using it is so you don't have to explicitly call Dispose() - instead, > > > you wrap your code around a "using" block. The using block will call > > > Dispose() automatically at the end, or if an exception is thrown. > > > > You can do whatever you want inside of Dispose() - close connections, > > > save files, etc. The method itself is just a normal method, that can > > > do anything any other method can do. It doesn't make the object > > > itself null or automatically take it out of scope, but in most cases > > > it does make the object unusable. As long as you create the instance > > > properly, you won't have any problems. > > > > Example: > > > > using (MyClass myInstance = new MyClass()) { > > > // Do stuff with myInstance} > > > > // myInstance is now out of scope > > > > is the same as: > > > { > > > MyClass myInstance = new MyClass(); > > > try { > > > // Do stuff with myInstance} > > > > finally { > > > myInstance.Dispose(); > > > > } > > > }
