Should a class that will run only once contain a static constructor?

Question

I am beginning to learn OOP programming with C#. Concerning design, it makes sense to me to use a static constructor for the main class of my program, considering this class contains code that will run only once (my whole program is very simple and consists of a single .cs file).

For example, here's a sample code using normal constructor:

class Program
    {
        const string file = @"C:\Program Files (x86)\myapp\log.txt";
        int status;

        static int Main(string[] args)
        {
            var myObj = new Program();
            return myObj.status;            
        }

        public Program()
        {
            int retCode;

            try {
                //  lots of procedures using the file

                retCode = 0;   // ok
            }
            catch (Exception ex) {
                Console.WriteLine(ex.Message);

                retCode = 999; // specific error
            }

            status = retCode;
        }
    }

Here follows the same structure, but using static constructor, as I think it's adequate. Notice status access was changed as well.

class Program
    {
        const string file = @"C:\Program Files (x86)\myapp\log.txt";
        static int status;

        static int Main(string[] args)
        {
            return Program.status;
        }

        static Program()
        {
            int retCode;

            try {
                //  lots of procedures using the file

                retCode = 0;
            }
            catch (Exception ex) {
                Console.WriteLine(ex.Message);

                retCode = 999;
            }

            status = retCode;
        }
    }

Question: Is my assumption correct, of using the second code instead the first one? Or am I missing something? In other words: Which one is preferable (considered better design)? And is there something fundamental on static constructors that will cause me trouble in this case?

@Legends I guess this is the entry-point for the program here ;) — Random Dev, Apr 29 '15 at 13:46
May be not directly related, but instead of having a single class with program entry point `Main` and the code, Have two separate classes, one with Entry Point *(Program)* and the other with your business logic. Later you can decide to have that class as static or non static. — Habib, Apr 29 '15 at 13:46
What do you think this is gaining you over just having this same code inside `Main` rather than the constructor? — Damien_The_Unbeliever, Apr 29 '15 at 13:51
@Damien_The_Unbeliever I may be biased by the "all there is are classes", I guess — first timer, Apr 29 '15 at 13:59
The first way is bad because of the unusual way the Program class and the Main function interact. The second way is worse as it unnecessarily relies on a function call being made automatically at a certain point in execution by the CLR as opposed to having an actual visible call in the code which is way clearer, and this is completely unnecessary in this program. — svinja, Apr 29 '15 at 14:05

C.Evenhuis · Accepted Answer · 2015-04-29T14:06:22.227

4

Try to avoid the use of static constructors as much as possible. Unlike instance constructors, you cannot actively invoke a static constructor - it is ran when the type is first being used (which may change due to optimalisation or even obfuscation).

Also try to avoid doing "work" in a constructor. The constructor is meant to construct the instance, and nothing more.

So in both cases, I would move the functionality to a method. That method can then have an actual return value, rather than setting a property. Since you're not maintaining any state (Program.status is then turned into a return value) you can safely make that method static.

edited Apr 29 '15 at 14:06

answered Apr 29 '15 at 13:59

C.Evenhuis

25,996
2
58
72

Thank you, very clear explanation. Do you recommend I just put the code inside the `Main` method, like someone seems to suggest in the comments? – first timer Apr 29 '15 at 14:49
2

As long as it does not grow too big, sure. But either way I'm afraid you'll still be creating a procedural program instead of an OOP one. – C.Evenhuis Apr 29 '15 at 15:07

score 2 · Answer 2 · answered Apr 29 '15 at 13:55

The code supplied does exactly the same thing except in the first instance you are creating the object Program instead of using the static members. This would be creating extra overhead for your application. Now in this instance there really isnt a reason to choose either of the methods as the overhead is negligible.

However in the first instance the value status is instance based. Therefore only the instance of Program has the value of status. Therefore, if status is an instance based field where multiple instances of Program should maintain their own status field value, then you should use the first example.

score 0 · Answer 3 · answered Apr 29 '15 at 14:21

The OP is probably looking for the Singleton pattern. My personal opinion is that if a class will only ever be instanced once, there is very little reason for it to be a class in the first place, and there is less call overhead if all the methods of such a class were reverted to static C functions - but that is just my opinion.

Should a class that will run only once contain a static constructor?

3 Answers3