What to do when a form's class becomes too large?

Currently my m开发者_Python百科ain form has a ton of event handlers because there are a lot of controls. It is very similar to a paint application. I have condensed it down quite a bit and I am sharing event handlers whenever possible but the class is still around 1,000 lines of code. I realize that may not be much to all of you but it is considerably larger than the rest of my classes.

I have refactored a lot of code to other classes but all those event handlers still increase the line count by a large amount. I also started using region blocks to separate event handlers in to groups and that is working rather well but I still would like to know SO's opinion on the matter as to best organize a large amount of form event handlers.

Edit: So I've been using partial classes and I must say, I don't really like them that much. I'm not sure what to do at this point.

I may go back to using region blocks as I'm not sure user controls will help my problem at all. Honestly I did not mind the region blocks that much. That class was the only place I used them and it organized the different sections of the code quite nicely (Menu Event Handlers, Toolstrip Event Handlers, Drag and Drop Support, et cetera).

Still, if anyone still has any other ideas or would like to elaborate upon any posted thus far I'd be more than appreciative as I am still looking for a better solution to this problem.

1000 lines of code is nothing, and that should not be the basis for refactoring your code. Refactor your code where it makes sense; not just because a class contains more lines of code than your other classes. Some classes will require more code than others, and that's perfectly okay.

That being said, if it makes sense you can divide the controls into logical sections, and put them in user controls. Make sure that there is a good justification for doing so though, because otherwise you'll only be convoluding your code base.

I must remind you again though, don't split your code up just to reduce the lines of code.

You could either split the functionality into separate classes (e.g. creating UserControls like Ed has suggested), or think about using partial classes (where one class can be split among many files). I have found partial classes handy to group together related chunks of code, when the "main" class file is getting to large. Sometimes this is the first step in refactoring those chunks of code into separate classes and/or controls.

It's hard to make a concrete recommendation without seeing the code, but those are some of your options.

If you haven't already (you don't mention it) I would split out the various individual controls into UserControls. You can handle all of the events from within the UserControl class and only expose those events that the parent form must absolutely handle. These will likely be small in number and will drastically reduce the responsibilities of your main form.

For example, each tool button could live inside of a UserControl. The canvas control can maintain and instance of the tools control and so on. You can keep creating the composite controls where each upper layer becomes less complicated and most of the actual logic is handled below it.

I would suggest of using more OOP solution. Do not add UserControls, as you add more *complexity*. Let's try to maintain complexity you already have, but make things more clear, cause this is what really you're asking for, I believe.

DI like. In practise if you need to handle a lot of events for a lot of contorls, create ControlManagers, which accepts in ctor the control and subscribes to its events.

So for every control you will have it's own manager.

Advantages:

1. Clear separated code in different classe, so easy recognizable in case of problems and my be more clear from architectural point of view.

2. You don't break down your architecture with a lot ot delegated events between tons of controls and subcribers (one subscriber per control)

Sure you will need organise, by the way, the data flow between different classes. But it's by my experience, haven't to be a big problem.

EDIT

An example pseudocode:

UserControl1 mycontrol1; UserControl2 mycontrol2; 
public class MyControl1Manager  {
    public MyControl1ManagerFor1  (UserControl1 uc1) {
          //subscribe to events of uc
          // here all code to handle events
    }
     public MyControl1ManagerFor2  (UserControl2 uc2) {
          //subscribe to events of uc
          // here all code to handle events
    }
}

and somewhere in code:

   MyControl1ManagerFor1  controlManager1 = new MyControl1ManagerFor1  (mycontrol1);
   MyControl1ManagerFor2  controlManager2 = new MyControl1ManagerFor2  (mycontrol2);

Something like this.

Hope this helps.

Once I had a form that became really big. It showed the same information in many various ways. To reduce number of code in single file I used an approach similar to UserControls. All the GUI elements were placed on the form, but their initialization and handlers were maintained by helper classes. They were equivalents of UserControls, but without GUI interface. These classes were initialized in main form's constructor:

SideViewHelper sideView = new SideViewHelper(parentForm, gridControlMaster, gridControlDetail, buttonSubmit);

All the logic that handles the gridControl events, button events are handled inside the helper class.

After the initialization the main form (parentForm) may change state of many UI items by single call of ViewHelper's method.

These classes are created for this only form and are as lightweight as possible.