Instantiating the class that contains static void Main()

I am reviewing a co-worker's C# console app, and I see this snippet:

class Program
{
    static void Main(string[] args)
    {
        Program p = new Program();
        p.RealMain();
    }

    开发者_开发问答... non-static RealMain function
}

Presumably, he's doing this because he wants to have instance-level fields, etc.

I haven't seen this before, but this style bugs me. Is it a common and accepted practice?

There is a school of thought that says that the main() function of object oriented code should do as little as possible. Main() is an "ugly" throwback to procedural code design, where programs were written in one function, calling subroutines only as necessary. In OOP, all code should be encapsulated in objects that do their jobs when told.

So, by doing this, you reduce the LOC in the main() entry point to two lines, and the real logic of the program is structured and executed in a more O-O fashion.

It makes sense to me.

In particular, you may want to add just enough logic into Main to parse the command line arguments - possibly using a generalized argument parser - and then pass those options into the constructor in a strongly-typed way suitable for the program in question.

Albin asked why this would be necessary. In a word: testability. In some cases it's entirely feasible to at least test some aspects of a top level program with unit tests or possibly integration tests. Using instance fields instead of static fields (etc) improves the testability here, as you don't need to worry about previous test runs messing up the state.

if you want to get non static functions you have to do like this.

class Program
{
    static void Main(string[] args)
    {
        Program p = new Program(); // dependency of the class will be there.So not a good practice
        p.RealMain();// if you want initalize, you have to go like this or better you can do it in some other class.
    }

    void RealMain(){} 
}

Never seen it before. If you want to go with this pattern, create a separate Program2-class with RealMain and instantiate that instead.

Why do you need instance level fields? Is static fields not enough?

There could be a benefit if you internally want to instantiate many Program classes.

I don't see anything particularly wrong with this approach, I just don't have seen it before.

Application entry point is always defined as static void Main(...).
You can decide to write your code inside Main() or use this method to run something else located elsewhere... it's up to you decide...

The accepted practice is to create an instance of a separate class which can contain anything you need. The above snippet looks weird at least :).

If it was any other class but "Program" the question wouldn't have come up. This design gives you the opportunity to instantiate multiple instances of "Program", maybe threaded in the future, so why not. I'm with KeithS here: As few as possible in static void Main.

I see this a lot, particularly for quick console programs knocked up to try something out, or test something.

Visual Studio practically encourages it - if you ask for a new Console program, it generates a single file, with a class containing only a Main method.

Unless you are doing something complicated, which requires more than 1 class, or something very simple, which doesn't require a class at all (i.e. all methods and variables static) why would you not do it this way?