我想知道在构造后设置对象的属性是否有优势，而不是在构造函数中。在构造函数中设置所有对象的属性OR初始化后设置对象属性
我使用的对象的属性创建起来很昂贵，所以在我看来，我应该在创建对象后设置属性。但是，当使用这些对象时，我不得不质疑该属性是否已设置，我宁愿假设它已设置。
特别适用于我的问题：比方说，我们有一个用户对象与朋友列表属性（用户数组）。如果必须设置好friendslist属性，那么每个“朋友”用户都必须使用自己的好友列表进行初始化......并且这将永远持续下去？但是，好像朋友列表适合作为用户的属性 - 那么我们是否将用户列表与用户分开，或者可以随后设置好朋友列表？
希望对此事有所了解，谢谢。
理想情况下，对象不应该具有无效状态，因此将对象直接构建到已配置状态应该更可取。
但是，您将遇到您使用的语言的细节。例如，在C++中，有两种力量可能会促使你反对：
其他语言可以做一些掩盖问题的语法糖。例如。 C＃有object initializer构造，如new A() {foo="x", bar="y";}，这使得它难以（并非不可能）使用处于中间未初始化状态的对象。
我通常选择在构造函数中初始化对象的所有属性。这里是我的推理：
你可以不小心设置一些对象的属性和现在其他的，在伪代码：
obj = new Obj(prop_a, prop_b, prop_c) // Error if not all three properties are set
method_requiring_all_three_values_are_initialized(obj)
VS
obj = new Obj() //No error, becuase constructor doesn't take the arguments
obj.set_prop_a(val);
obj.set_prop_b(val_2);
method_requiring_all_three_values_are_initialized(obj) // Runtime error
而且，如果对象是不可变的（在构建它之后你不能修改它），所以你的代码会更容易维护，因为你不必担心对象的状态。见Mutable vs immutable objects
但是，如果你的剖析代码和对象属性的早期初始化后变成透明的瓶颈，你可以重构后面的代码初始化为优化，我敢肯定，你听说过高德纳报价：
“我们应该忘记小的效率，讲的 时间约97％：过早的优化是所有罪恶的根源”
为了您的具体问题，我会小号从用户分离的朋友列表，因为它会使用户对象更容易推理（你不必担心它设置了什么状态，或者如果属性定义得很好，你只知道用户是用户... ）您可以拥有一个数据结构和函数，它接受一个用户对象并返回其相应的好友列表。
比方说，我们有一个用户对象与一个friendslist属性（用户数组）。如果必须设置好friendslist属性，那么每个“朋友”用户都必须使用自己的好友列表进行初始化......并且这将永远持续下去？但是，好像朋友列表适合作为用户的属性 - 那么我们是否将用户列表与用户分开，或者可以随后设置好朋友列表？ - 将这添加到我的q。 – Titus
苹果和橘子。 [延迟加载]（http://en.wikipedia.org/wiki/Lazy_loading）与Eager加载是一个非常**不同的问题。阅读[代理模式]（http://en.wikipedia.org/wiki/Proxy_pattern）。 –
延迟加载的概念很有趣，但肯定会延迟加载导致对象设置自己的属性？ – Titus