Most Efficient Way To Declare Classes

[KeysCoder]

I'm not exactly a newbie but I need a better understanding of how .net deals with instances of classes that are no longer used.

The way I understand it, the garbage collector will only reclaim resources when it needs to. So if I declare an instance of a class with a procedure-level variable, what happens after the procedure executes? The variable no longer exists but what about the instance of the class? It should still be in memory. Won't an entirely new instance be generated and abandoned every time the procedure executes?

 

[JuggaloBrotha]

I think you still have a couple of things mixed up there. When you run a procedure, all of the procedure variables will be given a null pointer so when the procedure runs again the variable gets re-created (different pointer) which means you can run a procedure x number of times and each one has it's own variable and when the garbage collector comes along, it frees up the memory of all the variables that have null pointers.

This is also true of classes too, when your variable (of the class) falls out of scope or you set it to nothing it's given a null pointer along with all of the variables that it has too.

This is also true at the code block level too, declare a variable inside an If... End If block then try using it after 'End If', it wont work because the variable declare has been given a null pointer because it fell out of scope and is simply waiting to be cleaned up by the GC (garbage collector)

 

[KeysCoder]

That's pretty much what I thought. That just seems wasteful of memory. If a class is going to be used multiple times during the lifetime of the application, does it make more sense to instantiate it once as a friend or public variable so that it doesn't continue to go out of scope and make more work for the GC? As I understand it, reclaiming resources is very expensive in terms of CPU cycles so is it better to declare classes globally unless they are only going to be rarely used?

 

[JohnH]

In best OOP practice you should use the narrowest scope possible and let GC worry about managing memory.

 

[KeysCoder]

In best OOP practice you should use the narrowest scope possible and let GC worry about managing memory.

Wow.

How about class size and complexity? I've tended to code large classes, often incorporating over a dozen different related procedures - much like code modules in older versions of vb. That seems like the wrong strategy if I were to go with a narrow-scope, instantiate and discard practice. Does a good OOP application consist of a large number of classes, each as small and specialized as possible rather than a small number of larger and more generalized classes?

 

[JohnH]

I think the .Net framework library is a good example of OOP, judge for yourself, but you'll never see the use of an instance method of a class leave the result in a shared variable.

 

[KeysCoder]

Hmm. Thank you; that is helpful.

I've been using vb2005 since its inception but lately I have come to feel like I'm still locked into the old way of doing things. I'm using classes as if they were code modules. I've just had a hard time getting my head wrapped around with the way .net handles garbage collection.

The way I understand it, the GC only takes care of managed resources and that it doesn't know how to deal with unmanaged resources - correct? So unmanaged resources in a class instantiation need to be properly disposed of before that instantiation goes out of scope?