何時使用屬性代替函數

Question

這可能是個人喜好問題，但是何時在代碼中使用屬性而不是函數

例如要獲取錯誤日志，我可以說

string GetErrorLog()
{
      return m_ErrorLog;
}

或者我可以

string ErrorLog
{
     get { return m_ErrorLog; }
}

您如何決定使用哪個？ 我的用法似乎不一致，我正在尋找良好的一般經驗法則。 謝謝。

Answer 1

如果滿足以下條件，我傾向於使用屬性：

• 該屬性將返回一個邏輯值
• 很少或不涉及邏輯（通常只返回一個值，或執行小的檢查/返回值）

如果滿足以下條件，我傾向於使用方法：

• 返回值將涉及大量工作-即：將從數據庫中獲取它，或者可能需要一些“時間”
• 獲取或設置值涉及很多邏輯

---

此外，我建議您參閱Microsoft的《財產使用設計指南》 。 他們建議：

當成員是邏輯數據成員時，請使用屬性。

在以下情況下使用一種方法：

• 該操作是一個轉換，例如Object.ToString。
• 該操作非常昂貴，以至於您希望與用戶進行交流，以使他們應考慮將結果緩存。
• 使用get訪問器獲取屬性值將產生明顯的副作用。
• 連續兩次呼叫成員會產生不同的結果。
• 執行順序很重要。 請注意，類型的屬性應該能夠以任意順序設置和檢索。
• 該成員是靜態的，但返回可以更改的值。
• 成員返回一個數組。 返回數組的屬性可能會引起誤解。 通常，必須返回內部陣列的副本，以便用戶無法更改內部狀態。 這加上用戶可以輕松地認為它是索引屬性的事實，導致代碼效率低下。 在下面的代碼示例中，每次對Methods屬性的調用都會創建該數組的副本。 結果，將在以下循環中創建2n + 1個數組副本。

Answer 2

這是Microsoft的准則：

在屬性和方法之間進行選擇

• 如果成員表示類型的邏輯屬性，請考慮使用屬性。

• 如果該屬性的值存儲在進程內存中，並且該屬性僅提供對值的訪問，請使用屬性而不是方法。

• 在以下情況下，請使用方法而不是屬性。

  • 該操作比字段設置要慢幾個數量級。 如果甚至考慮提供操作的異步版本以避免阻塞線程，則該操作很可能過於昂貴而無法成為屬性。 特別是，訪問網絡或文件系統的操作（一次初始化除外）應該很可能是方法，而不是屬性。

  • 該操作是一種轉換，例如Object.ToString方法。

  • 即使參數不變，每次調用該操作都會返回不同的結果。 例如，NewGuid方法每次被調用時都返回一個不同的值。

  • 手術有明顯的副作用。 請注意，通常不認為填充內部緩存是可觀察到的副作用。

  • 該操作返回內部狀態的副本（這不包括在堆棧上返回的值類型對象的副本）。

  • 該操作返回一個數組。

Answer 3

當屬性的明確含義是“從對象中獲取某些價值”時，我將使用屬性。 但是，使用一種方法是交流的好方法，“這可能要花很多精力才能返回”。

例如，一個集合可以具有Count屬性。 合理的做法是假設一個收集對象知道當前持有多少個項目，而不必實際遍歷它們並對其進行計數。

一方面，這個假設的集合可以具有GetSum（）方法，該方法返回持有的所有物品的總和。 相反，該集合只是輕松地具有Sum屬性，但是通過使用一種方法，它傳達了一個想法，即該集合必須做一些實際工作才能獲得答案。

Answer 4

如果我可能影響多個字段，則永遠不會使用屬性-我將始終使用一種方法。

通常，我只使用公共字符串ErrorLog {get; 私人套裝； }屬性的語法，將方法用於其他所有內容。

Answer 5

除了Reed的回答，當該屬性只會像獲取諸如事件日志之類的資源時一樣，是一種吸氣劑。 我嘗試並僅在沒有副作用的情況下使用屬性。

Answer 6

如果在一個屬性中發生的事情不多，那么它應該是一種方法。 例如，如果您的ErrorLog getter屬性實際上正在讀取文件，那么它應該是一種方法。 訪問屬性應該是快速的，並且如果要進行大量處理，則應該是一種方法。 如果訪問類的用戶可能不會期望的屬性有副作用，那么它可能應該是一種方法。

有.NET Framework設計指南書，其中非常詳細地介紹了此類內容。