The pattern you mentioned isn't necessarily the pattern used in all programs. For example, if I want to make a program that reads messages, processes them, and sends output somewhere, I might have a
main structure that's more like this:
public static void main(String args)
Reader reader = new Reader(args);
Writer writer = new Writer(args);
Processor processor = new Processor(args);
The gist here being that the thing that is launching parts of my application is not solely using one class, like in your examples. Here I would likely put the
main function into a
MyProgramLauncher class, because it's not directly tied to any single class, and we could potentially be adding more classes in the future(initializing logging, database connection, graphics engine, etc)
main is also a logical place to check for all of the preconditions of running your program. Eg. If you can't connect to your database, you might want to fail early and tell the user to check internet connection settings and try again.
If I have a main method like your
FooServerLauncher, then I would put it in
FooServer. So long as there's one
main method, and it references nothing other than
FooServer, then it belongs in the
FooServer file. Alternatively, if you have multiple main files that utilize
FooServer, then they need to be in their own
Launcher style classes, so that the functionality of each 'executable' of your system remains separate.
Analyzing it with typical design metrics(when compared to having
Readability - If anything is reduced, because the thing doing the execution and the thing being executed are separate. And in a very literal sense you have to read two different files to understand what's going on.
Modularity - Increased, but I would say this is following the dogma of 'modularity' to a fault.
Maintainability - Is also reduced for similar reasons to readability. While maintaining
FooServer you likely need to alter
FooServerLauncher. I would argue it's much less likely to alter
FooServer and forget to update
main as needed if they're in the same file. Having the separate files introduces 'out of sight, out of mind'.
Coupling - High, because it's 100% dependent on the implementation of
FooServer. In your example,
main has initialization steps and starts
FooServer, which depending on your preferences may be too much coupling.
Cohesion - I would say low, for the same reason we have high coupling. If everything in
main exists to do something tied to
FooServer, then the logical place to put
main is in
For a couple of these I think you could argue they stay the same, but I'm not quickly coming up with ways in which they're improved. So, all things considered, having
main in a separate file seems to be equal-to or less-than having it in the same file.