Instantiating the class containing the main method

[Ed Dablin]

I don't know the reason why, but I feel uncomfortable instantiating the class containing the main method, as in this example:

public class Foo{
String s = "Hello, World!";
public static void main( String[] args){
Foo f = new Foo();
f.go();
}
public void go(){
System.out.println(s);
}
}

It feels more natural to keep the main method in one class, and create a second class for the purpose of instantiation.
For example:

public class Foo2{
public static void main( String[] args){
Bar b = new Bar();
b.go();
}
}
class Bar{
String s = "Hello, World!";
public void go(){
System.out.println(s);
}
}

Either method works. Is there a reason to prefer one over the other?
Should I just learn to get over it?

[Campbell Ritchie]

I prefer the second method because it gets you used to handling multiple classes.
If you create a command‑line application, you can remove the class with the main method and use its public interface behind a GUI. Then you put a new main method in, which calls the application via the GUI.

[Tony Docherty]

Campbell's point is valid and the second approach is more technically robust but I suspect most people just put the main method in their application class. So I would say use the second version if you feel more comfortable with it but just remember most code you look at will probably be written along the lines of the first version.

[Jayesh A Lalwani]

I suspect most books use the first method because the code is more concise. In real life, I use the second method. More often than not, the command line apps that we build tend to use some sort of IoC (either through our custom configuration driven factories, or Spring) to initialize the app, so it makes more sense to keep the main method that calls the IoC to initialize the app from the app itself.