We are taught to trust the .NET garbage collector. There is no reason to reuse an object when you can instantiate a new object. The .NET Garbage Collector is effective and we don’t need to complicate our code.

This philosophy is sound. Why have explicit Initialise/Finalise methods when you can just instantiate a new object. The old object is collected when there are no longer any references. Avoiding this complexity reduces the chance of a mistake by the programmer. Well okay, garbage collection is two-edged and can lead to really complicated ‘memory leaks’. But that’s a story for another day…

There are exceptions to the rule. Objects that contain heavy resources are a candidate for caching. But even this can be encapsulated. A good example is SqlConnection which is wrapper for pooled database connections. When you instantiate a new SqlConnection it takes a database connection from the pool and puts it back when you call dispose.

This is all reasonable and expected by experienced .NET programmers. But what you may not know is that user interface objects qualify as heavy resources. This includes all the controls that make up your user interface such as buttons, edits, labels, edits, graphics and all the layout panels.