什麼時候使用方法而不是類定義的屬性？

Question

與an earlier question of mine部分相關，我有一個系統，我必須將複雜數據存儲爲一個字符串。我不是將這些字符串解析爲各種單獨的對象，而是創建了一個包含所有這些對象的類，並且它具有一些解析器邏輯，將所有屬性編碼爲字符串，或者解碼字符串以獲取這些對象。這很好，很好。這個問題不是關於解析器本身，而是關於解析器邏輯的位置。將它作爲一種財產或作爲一種方法是更好的選擇嗎？

在屬性的情況下，說public string DataAsString，所述get存取將容納所述邏輯來編碼的所有數據轉換爲字符串，而set存取將在類實例解碼輸入的值和設置的所有數據的。看起來很方便，因爲輸入/輸出確實是一個字符串。

在方法的情況下，一種方法將是Encode()，它返回編碼的字符串。然後，構造函數本身可以存儲解碼字符串的邏輯並需要字符串參數，或者我寫一個Decode(string str)方法，它被單獨調用。無論哪種情況，它都會使用一種方法而不是屬性。

那麼，有沒有這些路徑之間的功能差異，在代碼的實際運行條件怎麼樣？或者它們基本上是否相同，然後歸結爲個人偏好選擇還是哪個更好？而在那種問題中，哪一個看起來更清潔呢？

Answer 1

沒有功能差異;從行爲角度來看，屬性只是get和set方法的對。

然而，性質，一般地，旨在是輕質的。如果你的財產的吸氣劑或二級吸收器正在進行實質性計算，那麼通常會鼓勵將它們移動到一種方法。

有明顯的例外（即延遲加載在ORM領域，其中get可能引發數據庫調用）。

Answer 2

就我個人而言，我的屬性是非常愚蠢的，只在極端情況下做某些檢查。即檢查參數是否爲空它將返回，如果是，則將其更新或拋出異常

讓我們以Person類爲例 Person.Name在此情況下作爲屬性有意義。 Person.Speak（）作爲一個屬性沒有意義。

這一切都取決於它執行的功能。

Answer 3

「名詞」：該約定是屬性不做實際的業務邏輯它們也沒有副作用，即改變對象狀態（比設定的值等）。

「動詞：方法有望做的工作，並有副作用

之類的東西。‘轉換’或‘分析’或‘編碼’聽起來像動詞給我，我會用方法

Answer 4

。如果您的類將在數據綁定情況下使用，那麼您需要的屬性。否則，我是指你的答案。

Answer 5

從技術上講，他們可以做同樣的事情。一般來說，如果有涉及複雜的處理，我把它放在一個方法而不是一個財產。這背後的主要原因（雖然我不是說人們應該這樣做），是有一個共同的看法，即屬性應該允許快速訪問數據，方法調用期望它可能需要幾個週期完成。人們應該這樣做嗎？絕對不是，但他們確實如此。

我喜歡使用方法來記錄與我的代碼交互的人，「嘿，這是一種方法，有一些處理正在進行，所以不要以爲你會得到一個直接的結果。」您也不能有異步屬性訪問。您可以啓動一個方法，並在結果返回時收到通知。

Answer 6

另一點沒有提及的是，如果一個對象上的一個或多個讀寫屬性被寫入，然後全部讀回來而沒有任何中介方法調用，則讀取的值應與寫入的值匹配。如果寫屬性Foo會導致讀寫屬性Bar的值發生變化，那麼在我看來，這是一個很好的信號，表示其中一個或另一個應該是一對明確的getter-setter方法，而不是屬性。 .net中有許多類違反了這個原則，但我認爲這種行爲是sl。不馴的。也許最嚴重的罪犯是Control的Visible財產。編寫該屬性會更新其狀態無法讀取的字段，同時讀取該屬性將返回某些計算的結果。更好的設計應該是具有讀寫隱藏屬性和只讀可見字段。順便說一句，稍微類似的說明，我會使StringBuilder的「Length」屬性爲只讀，但有方法來截斷或填充它;我唯一會擁有的讀寫屬性就是Value。