<p>I tend to implement UI functionality using fairly self-documenting void doSomething() methods, i.e. if the user presses this button then perform this action then enable this list box, disable that button, etc. Is this the best approach? Is there a better pattern for general UI management i.e. how to control when controls are enabled/disabled/etc. etc. depending on user input?</p>

<p>Often I feel like I'm veering towards the 'big class that does everything' anti-pattern as so much seems to interact with the 'main' form class. Often, even if I'm including private state variables in the class that have been implemented using a relatively modular design, I'm still finding it grows so quickly it's ridiculous.</p>

<p>So could people give me some good advice towards producing quality, testable, decoupled WinForms design without falling into these traps?</p>

I would only put UI logic in the Form class and put any application logic in its own class:
```
```
class Form1 : Form
 {  
    void Button1_Click
     { 
       Program.DoCommand1();
     }
 }

static class Program
{
  internal static void DoCommand1() {/* ... */}
}
```
```