Oop 是否应该创建一个新类；“开始”；在施工过程中会发生什么？

上下文：.NET，C#，但问题是关于OOP的

当我编写一个应该充当“服务”的类（如套接字侦听器或计时器）时，我看到了两种编码方法：

创建一个构造函数，并在构造函数内部立即启动后台任务。例如：

public class MyTimer
{
    private readonly TimeSpan interval;

    public MyTimer(TimeSpan interval)
    {
        this.interval = interval;
        StartTicking();
    }

    private void StartTicking()
    {
        // do the ticking logic
    }
}

创建接受类设置的构造函数，并添加用于启动的显式方法：

public class MyTimer
{
    private readonly TimeSpan interval;

    public MyTimer(TimeSpan interval)
    {
        this.interval = interval;
    }

    public void StartTicking()
    {
        // do the ticking logic
    }
}

我倾向于认为第二种方法更好：

A.构造函数仅用于创建有效实例，使其保持最小和干净

实际使用我的类的开发人员就不那么惊讶了

C.硬件资源没有被过度使用，因为“服务”类不会立即使用它们

---

你觉得怎么样？这仅仅是一个编码风格的问题，还是更重要的问题？

保持构造函数的最小值，并要求调用代码调用特定的函数，以便执行除最简单的初始化之外的任何操作。例如，这就是类在.NET中所做的

除了避免调用构造函数的人感到意外之外，这还允许您更好地使用依赖项注入（即，将您的类注入到需要它但不希望正确使用它的类的构造函数中）

---

我还发现，某些类型的bug出现在构造函数中时比出现在其他方法中时更难捕获。

我所看到的几乎每一个服务类型类都公开了启动和停止它的方法。如果是自动启动，通常是非常明确的（类名可能是MyAutostartingTimer或其他东西）

不要在构造函数中开始运行

• API的用户不会期望这样，这会使类更难使用
• 从异常处理的角度来看，您希望能够报告在构造对象时发生的错误，而不是在执行期间发生的错误
• 如果您想要执行静态工厂单例模式之类的操作，它会阻止共享对象的实例
• 我支持StriplingWarrior的观点，即有很多很好的理由，比如依赖项注入，其中需要首先创建对象，以便其他类稍后可以运行它