我想知道在構造後設置對象的屬性是否有優勢，而不是在構造函數中。在構造函數中設置所有對象的屬性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