嗨夥計我需要深入克隆一些自定義對象引用其他自定義對象，這些可能引用其他自定義對象...等等，你會明白。ICloneable Vs強類型函數與懶惰
我只是在文檔&受孕階段，因此不想做對。
Q1。爲什麼實現ICloneable並返回一個對象，當你可以編寫一個強類型自定義函數來返回克隆的正確對象類型？ Q2302。這些對象不是很大，我不介意做最初的繁重複制每個元素，但懶惰我可以memberwise克隆對象，然後再次爲引用成員添加特定的代碼，這將創建一個需要鑄造，所以什麼是更有效率在cpu週期方面？
任何想法，意見&沉思的歡迎。
請參閱536349由於不實施ICloneable的原因;基本上你可以定義你自己的（強類型）接口並使用它，只要它正確記錄它創建了深層副本，我就沒有發現任何問題。
接口的目的是讓人們可以在支持接口的對象上進行操作，而不必擔心對象實際是什麼。不知道iCloneable.Clone實際上會對任何給定的對象執行什麼操作，只知道一個對象支持iCloneable是非常沒用的。
集合類型擁有一個受保護的BaseClone方法，並且它們具有派生類型可以使其公開（這樣做可以讓人從派生類中派生可克隆和不可克隆類型）集合）。像Dictionary這樣的支持Clone方法會比包含一個拷貝構造函數更好，因爲拷貝構造函數的參數可能是一個從Dictionary中派生出來的類型，但在內部顯着不同。
對於克隆接口是有用的，它必須包含由哪些項目可以說他們怎麼想克隆一個屬性（如-1-類型是不可改變的，不需要克隆; -2-克隆類型可能會破壞它; - 該類型支持克隆），並指定DeepClone操作將檢查所有對象以確保它們不介意被克隆，並且如果是這種情況，則會克隆所有嵌套的可變對象。不幸的是，框架中沒有這樣的東西。
具有接口，以指示一個對象可以複製，則可以是有用的，如果一組派生類型包括可複製的和非可複製的版本。如果某種類型的衍生物可能無法支持克隆，則應該保護該類型的克隆方法;該類型的可複製版本應該從中派生，但其他類型應該從非可複製版本派生。
例如，一個可具有帶派生類型包括CloneableWidget和SuperWidget（這是不可複製的）一個類型的widget。 SuperWidget可以有一個派生類型CloneableSuperWidget（以及其他一些會在克隆時破壞的）。如果一個人希望能夠與類型的widget的所有可複製的，衍生的工作，一個人必須要同時檢查的對象從派生的Widget，而且它是可複製的。將iCloneable添加到可複製的衍生產品將允許檢查這樣的對象。