方法VS物業在C＃中 - 有什麼區別

Question

可能重複：
Properties vs Methods

在方法，你可以輸入一些代碼和屬性了。例如我有一個屬性名稱。當類名更改時，我想從數據庫中獲取一些數據並更改我的對象的狀態。我可以添加此代碼來設置我的屬性的一部分。其他解決方案是將set part更改爲private，並添加名爲SetName的方法，並在此方法中添加我的代碼。

那麼有什麼區別？什麼時候把getter/setter的一些代碼和創建自己的方法用於改變我的屬性和我的類的其他部分是不好的？

Answer 1

這裏是一個很好一套指引何時使用性能相從Bill Wagner（固定鏈接）方法

• 使用一個屬性當所有這些都是真的： 的干將應該是簡單的，因此不太可能拋出異常。請注意，這意味着沒有網絡（或數據庫）訪問。要麼可能會失敗，因此會拋出異常。
• 他們不應該彼此依賴。請注意，這將包括設置一個屬性並影響另一個屬性。 （例如，設置FirstName屬性會影響組成名稱+姓氏屬性的只讀FullName屬性，這意味着這種依賴關係）
• 它們應該可以按任意順序設置
• getter沒有可觀察副作用請注意，本指南並不排除某種形式的物業惰性評估。
• 該方法必須始終立即返回。 （請注意，這排除了進行數據庫訪問調用，Web服務調用或其他類似操作的屬性）。
• 如果成員返回數組，則使用方法。
• 重複調用getter（無中介代碼）應返回相同的值。

• 重複調用setter（具有相同的值）的調用應該不會影響單個調用。

• get不應該返回對內部數據結構的引用（請參閱第23項）。一種方法可以返回一個深層副本，並可以避免這個問題。

Answer 2

給定一個屬性這樣

private string _name; 
public string Name { get { return _name; } set { _name = value; } } 

就可以寫出以下兩種方法：

public string get_Name() { return _name; } 
public void set_Name(string value) { _name = value; } 

這起相同作用。實際上，這正是編譯器在創建屬性時爲您做的。

一般來說，當他們內部的代碼開始感覺「昂貴」時，我會避開屬性，如果這樣做有任何意義。我希望屬性感覺像字段（在特定時間發生受控副作用），所以它們應該是輕量級的。

Answer 3

屬性不過是一些語法糖。 在某些情況下，最好定義屬性而不是方法，因爲它更清晰/更具可讀性。

設計指南指出，當你實現的功能很昂貴時，一種方法應該優於一個屬性。

實際上，一個屬性是作爲一個或兩個方法實現的;取決於你的財產是否有二傳手。該屬性被翻譯成get_xxx和set_xxx方法。

Answer 4

每當我遇到需要將代碼放在getter/setter中時，我將代碼放在一個私有方法中，並從getter/setter中調用該方法。這種方式的代碼是可用的方法調用，我應該在別處需要它。不知道這是你正在尋找的答案，但它只是我使用的一種方法論。

Answer 5

本質上屬性是幾個方法 - getProperty和setProperty。這只是對事物的約定/簡化。

假設屬性吸氣劑沒有副作用（好 - 它們可能有一些副作用，如延遲加載）。

Answer 6

方法做些什麼。這就是爲什麼他們通常在那裏有動詞的地方。

屬性返回數據。

該行很簡單，如果某個屬性不是訪問類內部數據存儲區，則該屬性應該成爲方法。

例如，如果你是一個名爲NumberOfQuetions屬性的用戶。如果它必須去數據庫以獲得應該成爲方法的問題的數量。如果它正在返回一個內部商店，即使內部商店已經完成了一些邏輯，您也可以將其保留在get中。

Answer 7

這可能不是最重要的區別，但的差異之一是，調試器可以被配置爲跨過性能（假設他們的代碼是微不足道的）。

Answer 8

基本上沒有區別（setter中的保留標識符「value」除外）。

Getters和setter被內部翻譯成標準方法，使運行時不知道某個getter或setter是否與某個屬性相關聯。術語語法糖通常用於這些便利構造。

但是，有一個重要的軟件工程好處：如果限制自己使用獲取和設置語義的getter和setter，則代碼會更容易理解。即只做必要的步驟來提供相應的財產。

做一些額外工作的常見用例是設置或獲取不直接由成員字段支持的屬性。例如，你有一個包含一個表示距離的值的類。你的班級可以提供兩個屬性：公里和英里，分別設置和設定吸取器。然後，您將在一對中進行簡單的轉換，並保存自己以存儲該值兩次。

作爲一般的經驗法則，您不應將任何代碼放在具有副作用的getter中。另外，setter中代碼的唯一副作用是setter所引用對象的狀態改變。

Answer 9

想到它，屬性不僅僅是語法糖。他們是您會員資料公開的會員代碼。

因此，爲您提供一個乾淨的圖層來檢索或輸入來自您代碼的成員數據的單個方面。

一個DTO例如只是一堆寫得很好的屬性，有效地分解數據和行爲。 如果沒有DTO，你會想象將DataGrid或Dropdown緊密地耦合到複雜的業務邏輯方法嗎？

簡單地說，方法實際上是在做這項工作......屬性既可以激發行動，也可以獲得狀態。

雖然，您可以在您的屬性中使用方法代碼......這不是它們的意思。甚至，如果你不得不向你的屬性中的另一個方法進行乾淨的調用，而不是實際寫入代碼。 HTH！