獲取方法的大小

Question

對於代碼行中的「獲取」大小是否有任何指導原則或普遍共識？我有一個成員的Get方法，在這裏很容易增長到30行代碼。我不確定在什麼時候這應該被拉入方法。但是，我只是將它稱爲GetMyString，然後將值賦給另一個成員，並在構造函數中調用它。

是否值得這樣做？

這對SO來說太主觀了嗎？

Answer 1

dcastro的答案是好的，但可以使用一些擴展：

• 它並不需要很長時間來恢復

那不是量化;讓我們量化一下。一個財產不應超過比獲得一個領域所需的時間長十倍。

• 它不連接到外部資源（數據庫，服務等）

這些都是緩慢的，因此通常第一個規則下摔倒，但這個第二個方面：故障應難得或不可能。屬性獲取者不應該拋出異常。

• 它沒有任何副作用

我想澄清的是，以觀察到副作用。屬性獲取器通常會產生副作用，即他們只計算一次屬性並稍後緩存它，但這不是可觀察的副作用。

不僅在哲學上讓屬性產生可觀察的副作用，它還會弄亂您的調試體驗。請記住，當您在調試器中默認查看對象時，調試器會自動調用其屬性getters並顯示結果。如果這樣做很慢，那麼這會減慢調試速度。如果這樣做可能會失敗，那麼您的調試體驗將充滿失敗消息。如果這樣做有副作用，那麼調試程序會改變程序的工作方式，這可能會使得很難找到該錯誤。您當然可以關閉自動屬性評估功能，但最好先設計好的屬性。

Answer 2

這是一個常見的不好的做法，將一大堆行放入Get方法中。 我在Visual Studio中安裝了一個名爲CodeMaid的東西。它有一種叫做CodeMaid Spade的方法，它爲每種方法評分並給你一個分數。分數越高，您的方法越糟糕。它也可以用於屬性。我建議你試一試，它有助於格式化，縮進和其他一些良好做法

Answer 3

這不是真正重要的大小（沒有雙關語意圖）。 它的確定有你的邏輯在吸氣只要

• 它並不需要很長時間來恢復
• 它不連接到外部資源（數據庫，服務等）
• 沒有關係沒有任何副作用

這些只是適當的財產使用的一些準則。

編輯

上述原則都有一個理想：屬性訪問應該表現得像數據訪問，因爲這是用戶所期望的。

從書有效的C＃由比爾·瓦格納：

屬性是可以從調用代碼類似 數據被視爲方法。這會給用戶的頭部帶來一些期望。他們將 看到一個屬性訪問，就好像它是一個數據訪問。畢竟， 這就是它的樣子。您的財產訪問者應該不辜負那些期望。獲取訪問者不應該有可觀察的一面 影響。 Set訪問者修改狀態，用戶應該能夠 看到這些變化。

屬性訪問器對您的用戶也有性能 的期望。屬性訪問看起來像一個數據字段 訪問。它不應該具有與簡單的數據訪問明顯不同的性能特徵，即 。

屬性訪問 不應執行冗長的計算，或者進行跨應用 調用（如執行數據庫查詢），或做其他冗長 操作，這將是與你的用戶對屬性訪問的期望 不一致。

加成阿爾貝託：http://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx

Answer 4

作爲一般準則，一個方法應該不會有在一個屏幕上比配合更多的行。如果你必須滾動，它太大了。將它分成更小的方法。

Answer 5

這不一定是壞事，但如果是我，它會讓我緊張，我會試圖以某種方式嘗試並分解它。吸氣劑是一種簡單的方法，只要將整件事物拖入30多條線的方法就會浪費我的時間。我會努力把它切碎。例如。如果它是一個帶有一些檢查的循環，則將檢查提取爲方法或其他類型。