Proper class instantiation in C# and Winforms

Question

After spending the last two years as a C#/WPF/MVVM developer, I recently took over a VB/Winform project at a new company.

I've successfully converted the project to C#. I've been doing a large amount of research, trying to figure out the best methods for this project, but I'm trying to figure out exactly how much refactoring and re-configuring to do.

My issue is this: the previous developer created two huge static classes. There are 30+ forms that are used for a variety of tasks. Each form is called from an event driven by a button click on a "main menu" type of screen. When the program initializes, a function from one of these mega-classes is called that instantiates EVERY form. There are also an incredible number of statics and constants.

I've broken the constants out and created a specific class for them. I'm piecing apart the mega-classes into smaller, more manageable (and responsibility specific) classes, but I've got this incredibly large initialization function that instantiates all of these forms.

Thus, my questions (finally) are these: Is what I wrote above a resource nightmare? Or, is this some sort of normal VB/Winform design pattern that I should keep? Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?

Thank you for any direction you can give me. If I can provide more information to make this more specific, please comment and I will edit.

Answer 1

Is what I wrote above a resource nightmare?

Yes

Or, is this some sort of normal VB/Winform design pattern that I should keep?

Absolutely not. The design of the system is pretty much identical in VB and C#. With some very minor exceptions the difference between the languages is just syntax.

Should I re-write this so that each form/class is instantiated when the button calling that form is clicked, so it can disposed of when closed?

Yes in theory. The forms should operate just as they would if you were writing in C#. Of course if the original dev liked global state so much there could be all sorts of state lurking between one appearance of the form and the next.

There are a few features of VB that can lead weaker devs astray. The presence of the Module (essentially a static class, but sometimes more convenient) can lure some people into adding much more global state than they should. Also in VB, it automatically creates as needed a single, global instance of each form with the same name as the class. This can cause devs to confuse the form as a class and object - leading to the single instance of a form, rather than constructing and disposing as needed.