隱式轉換對象

下面的代碼演示了我有時會看到的模式，其中一個對象在作爲參數傳遞給多個方法調用時被隱式轉換。隱式轉換對象

var o = new MyReferenceType(); 
DoSomeWorkAndPossiblyModifyO(o); 
DoYetMoreWorkAndPossiblyFurtherModifyO(o); 

//now use o...

這對我來說是錯誤的（它幾乎感覺不到面向對象）。可以接受嗎？

來源

2010-02-02 Ben

你能澄清可以接受嗎？你的意思是從語言角度還是從開發/設計角度？ – macabail 2010-02-02 22:49:15

我的意思是從開發/設計的角度來看。我想多年的面向對象設計讓我更習慣於控制自己轉換的對象。 – Ben 2010-02-02 23:20:45

這是可以接受但通常不好的風格。通常的「好」的做法是：

DoSomeWorkAndModify(&o); // explicit reference means we will be accepting changes 

o = DoSomeWorkAndReturnModified(o); // much more elastic because you often want to keep original.

您介紹的方法是有道理的，當o是巨大的，使得它的一個副本在內存中是毫無疑問的，或者如果它是一個函數，你（和其他人=私人）使用非常頻繁，不想打擾&語法。否則，懶惰會導致一些真正難以檢測到的錯誤。

來源

2010-02-03 09:20:12

謝謝 - 這很好地表達了我原來的想法。 – Ben 2010-02-03 10:27:34

它完全取決於方法實際上做了什麼，除了修改該對象。例如，主要與在內存中保存某個狀態有關的對象可能沒有任何與在任何地方保持該狀態相關的任何內容。

這些方法可以用於加載數據庫中的數據，並用該信息更新對象。

但是！因爲我編程主要是在C＃，因此.NET，這是一個完全面向對象的語言，我真的寫你這樣的代碼：

var o = new MyReferenceType(); 
SomeOtherClass.DoSomeWorkAndPossiblyModifyO(o); 
SomeOtherClass.DoYetMoreWorkAndPossiblyFurtherModifyO(o); 

//now use o...

在這種情況下，其他類的實際名稱（或與其他類如果有2個參與者）會給我一個關於實際發生的事情和/或上下文的大線索。

例子：

Person p = new Person(); 
DatabaseContext.FetchAllLazilyLoadedProperties(p); 
DatabaseContext.Save(p); // updates primary key property with new ID

來源

2010-02-02 22:51:49

根據您的方法名，我認爲沒有什麼轉型隱。這種模式是可以接受的。另一方面，如果您的方法的名稱爲printO(o)或compareTo(o)，但實際上修改了對象o，則設計會很糟糕。

來源

2010-02-02 23:01:48 akf

隱式轉換對象

回答

相關問題