「Getters不應該包含大量的邏輯。」對或錯？

我傾向於作出一個隱含的假設，即getters只不過是一個訪問控制包裝器，而不是一個相當輕量的指令集來返回一個值（或一組值）。「Getters不應該包含大量的邏輯。」對或錯？

因此，當我發現自己編寫的處理器消耗更多，處理器耗費更大時，我感覺或許這不是最明智的舉動。在我自己的代碼中調用一個getter（特別是讓我們引用C＃中方法與getter調用之間存在語法差異的地方），那麼我就隱式地假設這些是輕量級的 - 事實上這可能不是案件。

這是什麼普遍的共識？除了使用其他人的圖書館，你是否寫沉重的獲得者？還是你傾向於將較重的吸氣者視爲「完整的方法」？

PS。由於語言的差異，我預計會有相當多的不同想法......

來源

2010-11-01 Arcane Engineer

在我看來，緩存是最大的問題。如果一個getter不打算改變對象狀態，那麼緩存一個可行的選項？對我來說，這是一個顯而易見的地方，它是用於原子讀取操作的。另外，語法糖：我喜歡例如。 C＃的getters。但是如果語言不能強制托馬斯答覆中引用的那種用法，那麼它是否應該嘗試（以Java爲例）？然後，應該只在方法的文檔中記錄性能。關鍵是，這都是非常主觀的。附：爲了防止戰爭，我是兩種語言的粉絲（還有其他許多人）。 – 2010-11-01 12:03:16

是的。 Getters應該訪問一個簡單的成員，或者應該計算並緩存一個派生值，然後返回緩存的值（後續獲取不帶交織集只應返回該值）。如果我有一個要做大量計算的函數，那麼我將它命名爲computeX，而不是getX。

來源

2010-11-01 01:42:16

謝謝，這對我來說是給出答案中最具信息性的。我認爲你提到緩存是勝利的一點。 – 2011-10-17 17:40:13

屬性獲取器旨在檢索一個值。所以當開發者打電話給他們的時候，有一個期望，那個電話會立即返回（幾乎）一個值。如果不能滿足這種期望，最好使用一種方法而不是屬性。

來源

2010-11-01 01:42:03

總的來說，我寫的是短而有效的。但是你可能有複雜的 - 你需要考慮如何使用吸氣劑。如果它是一個外部的API，你不能控制它如何被使用 - 所以要提高效率。

來源

2010-11-01 01:42:06 zekeyeehaw

我同意這一點。例如基於DateOfBirth的Age等計算屬性非常有用。但是我會避免複雜的邏輯，比如爲了計算對象屬性的值而去數據庫。在這種情況下使用方法。

來源

2010-11-01 01:49:10 lahsrah

我同意，對數據庫的調用對於getter來說似乎不是一件好事。 – Kirk 2010-11-03 00:45:39

我的意見是，getter應該是輕量級的，但是正如你所說的那樣，有一個廣義的「輕量級」定義，添加一個記錄器對於追蹤目的是很好的，可能還有一些緩存邏輯和數據庫/ Web服務檢索。哎。你的吸氣已經被認爲是沉重的。 Getter是類似setter的合成糖，我認爲這種方法更加靈活，因爲它們異步使用它們的簡單性。

但是沒有爲您的吸氣性能設置期望（可能試圖在咳嗽文檔中提到它），因爲它可能試圖從慢速源檢索新值。其他人當然正在考慮簡單對象的getter，但由於您的對象可能是您的後端對象的代理，所以我真的看不到太過分的性能期望值，因爲它可以幫助您使代碼更易讀，更易於維護。所以我的答案是，「它取決於」，主要取決於你的對象的抽象級別（低級對象的短邏輯，因爲值應該可以在setter級別計算，長級別可以在高級別級別計算）。

來源

2010-11-01 01:58:09 dvhh

將日誌記錄添加到getter會導致我懷疑代碼異味。並不是說它永遠不會發生，但我不得不考慮它。 – Kirk 2010-11-03 00:53:18

如果我正在編寫可能需要獲取某些內容的代理，那麼在異步調用獲取真實數據時，我可能會返回一個引用對象。然後，我仍然非常喜歡異步數據調用。我必須爲Silverlight學習它，現在只是喜歡它。 – Kirk 2010-11-03 00:59:21

From MSDN：

物業使用指南

使用方法時：
[...]

操作是要傳達給夠貴的用戶應該考慮緩存的結果。結果。

And also：

屬性和方法

之間進行選擇一定要使用的方法，而不是財產，在下列情況下。

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

來源

2010-11-01 01:59:55

+1參考 – 2010-11-01 04:37:10

這涵蓋了C＃，至少。我絕對同意異步調用不是以任何*語言獲得的。另外緩存問題真的讓我問這個問題。 – 2010-11-01 11:45:06

所有的一切，很少有我的方法是在時間，它會根據張貼由托馬斯的指導關係方面非常昂貴。但問題是，一般來說，調用getter不應該影響該類的狀態。我沒有問題寫一個吸氣劑，但實際上運行計算時調用。

來源

2010-11-01 02:05:41 Kirk

+1，這是我想知道是否有人會採取的觀點。當我編寫像遊戲和模擬這樣的實時內容時，往往針對網絡效率問題，我的觀點是關注每個週期的效率。 – 2010-11-01 12:08:17

當然有時候需要關心效率。（雖然大多數人的計劃真的不需要）。在這種情況下，我會平衡提前或按需計算的成本。對於我的大部分程序來說，這是一次洗牌，因爲大部分程序都用於綁定Silverlight或WPF。然後，每次更改時都會讀取一次。但就此而言，由於綁定問題，我使用getter和method。 – Kirk 2010-11-03 00:49:37

「Getters不應該包含大量的邏輯。」對或錯？

回答

相關問題