在定義變量的類中使用getter和setters？

Question

我一直在閱讀有關吸氣劑和吸氣劑的問題，我有一個問題。 在訪問聲明了變量的類中的變量時，是否應該使用getter和setter方法？ 似乎這里不需要getter和setter方法，因為變量是私有的並不重要，聲明它的類將始終可以訪問它。

還是僅在外部類要訪問這些變量時才使用getter和setter方法？

Answer 1

盡管該語言不需要您這樣做，但是在訪問通過getter和setter公開的私有字段時，最好使用getter和setter。 在某些情況下，我什至可以說，即使對於尚未直接公開（但尚未公開）的內部屬性 ，也有必要使用它們。

這樣做是一種很好的做法，原因是它會將讀取和修改私有字段的代碼隔離為一組方法。 這樣，您以后可以提供額外的驗證，甚至可以更改屬性在內部存儲的方式，而不必更改太多位置。

更改的一個示例可能是一個類，該類通過getter（訪問器）/ setter（誘變器）方法公開了某個屬性，該屬性最初存儲為該類中的私有字段。 后來，您意識到該屬性需要使用其他存儲庫-可能是從文件或數據庫等中讀取它。此時，如果僅使用了訪問和修改屬性的方法，則只需更改即可用於實現更改的accessor和mutator方法的代碼。

另一個示例是擴展類時的實例。 它提供了更好的封裝。

即使對於測試，也有必要抽象訪問邏輯屬性對私有“存儲庫”的訪問。

注意：我指的是作為類的屬性公開的私有成員的概念，即使Java不一定如此。

最后， 我不能太強調我的建議是使用方法而不是直接訪問私有成員，這就是：Recommendation 。 許多人都認為這是一種很好的做法，因此，我建議您遵循，但是如果您有充分的理由也不要遵循它！

Answer 2

簡單的答案是：由您決定。

有一種觀點認為應該始終使用訪問器，並且只能直接訪問訪問器中的變量，而永遠不要訪問它之外的變量。 這樣可以確保可靠地觸發您在訪問器中實現的所有內容。

還有另一種流派，說訪問者在那里是您班級的公共合同，而在班級內部，您可以自由地做自己想做的事。 有時，您可能希望設置一個值而不觸發在訪問器中實現的任何其他操作。

（幾年前，曾經有過關於使用訪問器的性能方面的爭論，而實際上並不需要“訪問”訪問器，但是對於當今的JIT編譯方法，這根本就不再是要考慮的因素。）

Answer 3

這取決於。

如果getter或setter不是最終的，並且打算在潛在的子類中覆蓋它，則甚至可以從類本身進行調用，以免繞過子類為訪問器添加的其他行為。

例如，假設子類希望每次更改某些屬性時都觸發事件。 為此，它將覆蓋此屬性的設置器。 但是，如果超類的其他某些方法不使用setter來直接修改屬性，則不會觸發該事件。 在這種情況下，使用基類中的setter很有意義。

Answer 4

沒有簡單的答案。 取決於您的訪問者的工作。 如果他們只是在那兒訪問變量，那么這並不重要……如果他們做一些邏輯，那么這取決於您是否要在類中使用該邏輯。

有很多示例，您不想使用類內部的屬性來訪問變量，但又不想讓外部實體在不通過屬性訪問器的情況下訪問該變量。

就是說， 我的觀察方式是：除非您有充分的理由不通過訪問器的邏輯，否則請使用它們。

Answer 5

IT也可以取決於您所使用的環境。例如，如果您在Android環境中進行Java編程，則鼓勵通過getter / setter方法直接訪問。 在其他環境中，可以鼓勵吸氣劑/設置劑的可維護性。

來自http://developer.android.com/guide/practices/design/performance.html上的Android開發人員文檔

避免內部吸氣劑

在像C ++這樣的本地語言中，通常的做法是使用getter（例如i = getCount（））而不是直接訪問字段（i = mCount）。 這是C ++的一個好習慣，因為編譯器通常可以內聯訪問，並且如果需要限制或調試字段訪問，則可以隨時添加代碼。

在Android上，這是個壞主意。 虛擬方法調用非常昂貴，比實例字段查找要昂貴得多。 遵循常見的面向對象編程實踐並在公共接口中具有getter和setter是合理的，但是在類中，您應該始終直接訪問字段。

沒有JIT，直接現場訪問的速度大約是調用簡單的getter的3倍。 使用JIT（在這種情況下，直接現場訪問與本地訪問一樣便宜），直接現場訪問的速度比調用簡單的getter快約7倍。 這在Froyo中是正確的，但將來在JIT內聯getter方法時會有所改善。

Answer 6

在課堂上，我使用私有成員。 如果事實證明，我需要訪問器中的額外邏輯才能從該類中運行，那么我將它們移到另一個中。 幫手，內部的，父母的，除了在當前類中含糊不清之外。

隨着類的重構，諸如此類的問題趨於泛濫，並可能留下一些痛苦且往往難以發現的錯誤。