Language agnostic 我在哪里可以找到一个简洁、写得很好的论点来反对这种初始化反模式，或者其他模式？

我的一位同事倾向于设计如下课程：

class ImportantClass
{
    public SomeClass ImportantField;
    public SomeOtherClass OtherImportantField;
    // etc.
}

他不会写构造函数。然后，无论他在哪里实例化这种类型，他的代码都将如下所示：

ImportantClass x;

try
{
    // This is problematic enough to begin with, as every field (which is public)
    // is set manually, which causes code duplication wherever this type is
    // instantiated as well as maintenance problems in the event new fields are
    // introduced or internal implementation is changed.
    x = new ImportantClass();
    x.ImportantField = new SomeClass();
    x.OtherImportantField = new SomeOtherClass();
}
catch (Exception ex)
{
    // ...what's even worse: now x can easily be in a totally invalid state,
    // with some fields initialized and some not.
    HandleAnyException(ex);
}

显然，上述是一个过于简单和夸张的例子；但我想你明白了

我发布这篇文章不是为了批评我的同事；相反，我想让他明白在开发这样的课程时存在的许多问题，并为他指出正确的方向。我个人觉得这个设计虽然很差，但很容易修复

我主要担心的是，如果我想说服他，我必须有一个有力、易于理解和简洁的论点，他不会想读一封两页的电子邮件，告诉他为什么我认为他的代码需要更改

有没有什么好的资源可以提供这种精心设计的论点，解决这种设计模式的缺点，或者其他不明智的设计反模式？如果存在的话，类似于常见软件设计错误概要的东西将非常有用

---

注：我意识到简单地谈论它是给出建议的最直接、可能也是破坏性最小的方式；我只是在想，如果有这样一个资源存在的话，我还可以再次引用这个资源，这将很好。

它违反了责任原则。如果ImportantClass需要另外两个实例才能正常工作，那么在其他任何事情发生之前，确保它们处于已知的良好状态是ImportantClass的责任。

该代码违反了Joshua Bloch的优秀著作《高效Java》中描述的几条原则，我强烈推荐这本书。例如，在公共实例字段上：

如果实例字段为非最终字段，或 是对可变变量的最终引用 对象，然后通过创建字段 公众，你放弃了 限制可存储在中的值 田野。这意味着你也要放弃 强制执行不变量的能力 涉及领域。还有，你放弃了 在需要时采取任何行动的能力 该字段已修改，因此具有 不支持公共可变字段 线程安全。即使某个字段是最终字段 并引用一个不可变的对象 公开你放弃的领域 切换到新系统的灵活性 内部数据表示，其中 该字段不存在

此外，这些公共字段没有实现封装

---

这本书还有很多关于如何安全正确地进行对象初始化的内容。可以说，您发布的代码存在很大问题。

我想让您的同事看一篇关于的文章。

您可以向他提到，这种编码方法违反了面向对象开发的三个基本概念之一，当然是封装

用户可以直接修改对象的状态，这使得调试变得非常困难，而私有方法是访问内部数据的唯一方法

更重要的是，他的客户机与他的类紧密耦合，因此，如果他想进行一些内部更改，则需要重新编译他的客户机，尽管发生的更改不会影响其使用

然而，事实是，与过去相比，在最近几年中，面向对象系统中数据封装的应用有所放松

例如，SPRING或LINQ等技术直接侵犯了试图归档IOC或“功能性”行为的实现细节的隐私

这种趋势的直接结果是C最近采用了自动属性，用于简化私有数据作为set/get属性的直接公开…

这违反了规则，因为作为类的使用者，我需要了解类的工作知识，才能使其正常工作，或者运行直到没有异常为止这将是一个巨大的痛苦在a$$

一些引语来自：

API应该易于使用且不易误用。做简单的事情应该容易；能够做复杂的事情；做错事是不可能的，至少是困难的

保持API没有实现细节。它们混淆了用户，抑制了发展的灵活性。什么是实现细节并不总是显而易见的：小心过度指定

---

哇！他们付钱让他写那样的东西？