Seperating UI code

[RunTimeError]

Hey guys,

I just have a question regarding the separation of UI code from business/logic code. I always seem to get in trouble for putting to much code in form classes. I don't understand where the line is drawn between code that needs to be in form/UI code vs code that needs to be put in a separate class. Further it seems a bit over kill to have to create a separate class and do logic in there just to do something simple. Lastly, what is the point? I really don't understand what the big deal is. I know that it is good practice but I mean is it really that big of an issue? In the example below I am getting the time and bringing up a message box. Now normally I would put this into the form code:

Form1.cs (UI Code)

int hour = DateTime.Now.Hour;

if(hour == 12)
{
      MessageBox.Show("It's time")
}

By definition this is logic so I need to make an entirely separate class to satisfy the "separation of UI" rule such as I have done below?

Form1.cs (UI)

timelogic timeClass = new timelogic();

if(timeClass.returnTime())
{
      MessageBox.Show("It's time")
}

timelogic.cs

public bool returnTime()
{
     int hour = DateTime.Now.Hour;

     if(hour == 12)
    {
        return true;
     }
     return false;
}

It seems to be a bit over kill. I get even more confused because I am using logic within my form class to bring up a message box so am I breaking the rule? Can someone explain the proper method for separating logic/business code from UI code?

[Diamonddrake]

That's really up to the programmer. If you work for a company that expects this, then its up to them, but if you are just writing software by your self it doesn't really matter.

The big selling point of putting logic in classes is portability. once you have written it once, you can easily use it in other applications. another thing is it keeps your code organized, so in a large application its easier to find and edit your code.

but writing a class for 10 lines of code that could easily be condensed into 5, that's just silly.

[crazy_coder]

As replied above, It depends on the type of program you are writing. The programmer should be able to draw the line where to put the functionality depending on the complexity, and requirements. Yes, you should not be too sensitive to this issue. it will suck your time in decision making of where to put the code rather writing a working solution.

[mikiurban]

Actually, it's not up to the programmer, it's up to whoever approves the code :) There are an unlimited degrees of "how much is too much" in either direction. If your boss/teacher doesn't think it's separated enough, then it isn't. Your next supervisor will most likely be different. It boils down to development speed vs. portability: it's faster to create code without all of this abstraction, but you may never be able to use it anywhere else.

For me, a good rule of thumb is "how often will I be using this logic?" and if it's more than in two spots, then I separate it out. For example, there are now several ways to open a file: File menu -> Open, or the button on the toolbar, or Ctrl+O, etc, so it makes sense to have a separate function that goes through the whole "show dialog, see if he clicks OK or cancel, read the file, prepare UI" process. In your example, if you only check the time in one place for your whole program, then separating it out may be overkill. But if you are checking it all over the place, then it makes sense.

Another way to look at it: if I have to make a change to this logic (in your example, what if you also need to compare it to 0, to handle midnight), how many places do you need to make the change? if you spend too much time trying to make changes to your code instead of programming, it might be a good idea to split it up.