Question

Context: .NET, C#, but the question is about OOP in general.

When I write a class that should act as a “service”, like a socket listener, or a timer, I see two approaches when it comes to coding it:

1. Create a constructor, and inside the constructor, immediately start the background task. For instance:

   public class MyTimer
   {
       private readonly TimeSpan interval;
   
       public MyTimer(TimeSpan interval)
       {
           this.interval = interval;
           StartTicking();
       }
   
       private void StartTicking()
       {
           // do the ticking logic
       }
   }
   

2. Create a constructor that accepts the class’ settings, and add an explicit method for starting up:

   public class MyTimer
   {
       private readonly TimeSpan interval;
   
       public MyTimer(TimeSpan interval)
       {
           this.interval = interval;
       }
   
       public void StartTicking()
       {
           // do the ticking logic
       }
   }
   

I tend to think that the second approach is better:

A. The constructor is used only for creating a valid instance, keeping it minimal and clean.

B. The developer who actually uses my class is less astonished.

C. The hardware resources are not overused, since the “service” class does not immediately use them.

What do you think? Is it only a matter of coding style, or is it more than that?

Answer 1

Don’t start running in your constructor.

• Users of your API won’t expect that, and it makes your class harder to use
• From an exception handling standpoint, you want to be able to report an error that happens when constructing an object, separately from an error that happens during execution.
• It prevents sharing instances of your object, if you ever wanted to do something like a static factory singleton pattern.
• I would second StriplingWarrior’s point that there are many good reasons, like dependency injection, where object creation needs to happen first so that some other class can run it later.