构造函数的任务是使对象进入可用状态。关于这个问题，基本上有两种观点。

一组人赞成两阶段建设。构造函数只是将对象带入一个休眠状态，在这种状态下它拒绝做任何工作。还有一个额外的函数来进行实际的初始化。

我一直不明白这种方法背后的原因。我坚决支持单阶段构造，即对象在构造后完全初始化并可用。

如果单阶段构造函数未能完全初始化对象，则应该抛出。如果对象不能初始化，则必须不允许它存在，因此构造函数必须抛出。

据我所知，没有人能提出一个相当明显的解决方案，同时体现了一阶段和两阶段结构的优点。

注意:这个答案假设是c#，但是这些原则可以应用于大多数语言。

一、两者的好处:

单程

一级构造通过防止对象以无效状态存在而使我们受益，从而防止了各种错误的状态管理和随之而来的所有错误。然而，这让我们中的一些人感到奇怪，因为我们不希望我们的构造函数抛出异常，而当初始化参数无效时，有时我们需要这样做。

public class Person
{
    public string Name { get; }
    public DateTime DateOfBirth { get; }

    public Person(string name, DateTime dateOfBirth)
    {
        if (string.IsNullOrWhitespace(name))
        {
            throw new ArgumentException(nameof(name));
        }

        if (dateOfBirth > DateTime.UtcNow) // side note: bad use of DateTime.UtcNow
        {
            throw new ArgumentOutOfRangeException(nameof(dateOfBirth));
        }

        this.Name = name;
        this.DateOfBirth = dateOfBirth;
    }
}

两阶段验证法

两阶段构造的好处是允许在构造函数外部执行验证，因此避免了在构造函数内部抛出异常的需要。然而，这给我们留下了“无效”实例，这意味着我们必须跟踪和管理实例的状态，或者在堆分配后立即丢弃它。这就引出了一个问题:为什么我们要在一个我们最终甚至不使用的对象上执行堆分配，从而进行内存收集?

public class Person
{
    public string Name { get; }
    public DateTime DateOfBirth { get; }

    public Person(string name, DateTime dateOfBirth)
    {
        this.Name = name;
        this.DateOfBirth = dateOfBirth;
    }

    public void Validate()
    {
        if (string.IsNullOrWhitespace(Name))
        {
            throw new ArgumentException(nameof(Name));
        }

        if (DateOfBirth > DateTime.UtcNow) // side note: bad use of DateTime.UtcNow
        {
            throw new ArgumentOutOfRangeException(nameof(DateOfBirth));
        }
    }
}

通过私有构造函数实现单阶段

那么，我们如何在构造函数中保持异常，并防止自己对立即被丢弃的对象执行堆分配呢?这是非常基本的:我们将构造函数设为私有，并通过指定的静态方法创建实例来执行实例化，因此只有在验证之后才能进行堆分配。

public class Person
{
    public string Name { get; }
    public DateTime DateOfBirth { get; }

    private Person(string name, DateTime dateOfBirth)
    {
        this.Name = name;
        this.DateOfBirth = dateOfBirth;
    }

    public static Person Create(
        string name,
        DateTime dateOfBirth)
    {
        if (string.IsNullOrWhitespace(Name))
        {
            throw new ArgumentException(nameof(name));
        }

        if (dateOfBirth > DateTime.UtcNow) // side note: bad use of DateTime.UtcNow
        {
            throw new ArgumentOutOfRangeException(nameof(DateOfBirth));
        }

        return new Person(name, dateOfBirth);
    }
}

通过私有构造函数异步单级

除了前面提到的验证和堆分配预防的好处之外，前面的方法还为我们提供了另一个漂亮的优点:异步支持。这在处理多阶段身份验证时非常方便，例如在使用API之前需要检索承载令牌。这样，您就不会得到一个无效的“签出”API客户端，相反，如果在尝试执行请求时收到授权错误，您可以简单地重新创建API客户端。

public class RestApiClient
{
    public RestApiClient(HttpClient httpClient)
    {
        this.httpClient = new httpClient;
    }

    public async Task<RestApiClient> Create(string username, string password)
    {
        if (username == null)
        {
            throw new ArgumentNullException(nameof(username));
        }

        if (password == null)
        {
            throw new ArgumentNullException(nameof(password));
        }

        var basicAuthBytes = Encoding.ASCII.GetBytes($"{username}:{password}");
        var basicAuthValue = Convert.ToBase64String(basicAuthBytes);

        var authenticationHttpClient = new HttpClient
        {
            BaseUri = new Uri("https://auth.example.io"),
            DefaultRequestHeaders = {
                Authentication = new AuthenticationHeaderValue("Basic", basicAuthValue)
            }
        };

        using (authenticationHttpClient)
        {
            var response = await httpClient.GetAsync("login");
            var content = response.Content.ReadAsStringAsync();
            var authToken = content;
            var restApiHttpClient = new HttpClient
            {
                BaseUri = new Uri("https://api.example.io"), // notice this differs from the auth uri
                DefaultRequestHeaders = {
                    Authentication = new AuthenticationHeaderValue("Bearer", authToken)
                }
            };

            return new RestApiClient(restApiHttpClient);
        }
    }
}

根据我的经验，这种方法的缺点很少。

通常，使用这种方法意味着您不能再将该类用作DTO，因为在没有公共默认构造函数的情况下反序列化到对象是困难的。但是，如果您使用对象作为DTO，则不应该真正验证对象本身，而应该在尝试使用对象上的值时使它们无效，因为从技术上讲，这些值对于DTO来说并不是“无效”的。

这也意味着当您需要允许IOC容器创建对象时，您将最终创建工厂方法或类，否则容器将不知道如何实例化对象。然而，在很多情况下，工厂方法本身就是Create方法之一。

对我来说，这是一个有点哲学的设计决策。

拥有实例是非常好的，只要它们存在就有效，从ctor时间开始。对于许多重要的情况，如果无法进行内存/资源分配，则可能需要从ctor抛出异常。

其他一些方法是init()方法，它本身存在一些问题。其中之一是确保init()实际被调用。

一个变体使用惰性方法在第一次调用访问器/突变器时自动调用init()，但这要求任何潜在的调用者都必须担心对象是否有效。(而不是“它存在，因此它是有效的哲学”)。

我也看到过处理这个问题的各种设计模式。例如，可以通过ctor创建初始对象，但必须调用init()来获得包含的、初始化的具有访问器/突变器的对象。

每种方法都有其利弊;我已经成功地使用了所有这些方法。如果不是在创建对象的那一刻就创建现成的对象，那么我建议使用大量的断言或异常，以确保用户在init()之前不会进行交互。

齿顶高

我是从c++程序员的角度写的。我还假设您正确地使用了RAII习惯用法来处理抛出异常时释放的资源。

Eric Lippert说有四种例外。

Fatal exceptions are not your fault, you cannot prevent them, and you cannot sensibly clean up from them. Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. Vexing exceptions are the result of unfortunate design decisions. Vexing exceptions are thrown in a completely non-exceptional circumstance, and therefore must be caught and handled all the time. And finally, exogenous exceptions appear to be somewhat like vexing exceptions except that they are not the result of unfortunate design choices. Rather, they are the result of untidy external realities impinging upon your beautiful, crisp program logic.

构造函数本身不应该抛出致命异常，但它执行的代码可能会导致致命异常。像“内存不足”这样的事情不是您可以控制的，但是如果它发生在构造函数中，嘿，它就发生了。

愚蠢的异常永远不应该出现在任何代码中，所以它们应该被清除。

构造函数不应该抛出恼人的异常(例如Int32.Parse())，因为它们没有非异常情况。

最后，应该避免外生异常，但如果在构造函数中执行的某些操作依赖于外部环境(如网络或文件系统)，则抛出异常是合适的。

参考链接:https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

由于部分创建的类可能导致的所有麻烦，我认为永远不会。

如果需要在构造过程中验证某些内容，请将构造函数设为私有并定义一个公共静态工厂方法。如果某些东西无效，该方法可以抛出。但是如果一切都检查出来了，它就调用构造函数，保证不会抛出。

Throwing an exception during construction is a great way to make your code way more complex. Things that would seem simple suddenly become hard. For example, let's say you have a stack. How do you pop the stack and return the top value? Well, if the objects in the stack can throw in their constructors (constructing the temporary to return to the caller), you can't guarantee that you won't lose data (decrement stack pointer, construct return value using copy constructor of value in stack, which throws, and now have a stack that just lost an item)! This is why std::stack::pop does not return a value, and you have to call std::stack::top.

这个问题在这里有很好的描述，检查第10项，编写异常安全的代码。