你自己的專案的話可以將屬性寫成 public 直接訪問，沒毛病，想咋寫咋寫。

但是你要是寫元件，寫框架的話就不建議了。

首先，你屬性許可權開的太高，那麼使用者可以隨意更改，但使用者並不知道具體實現細節，可能改完之後在後續邏輯流程中就報異常，還吐槽框架不好用。所以使用 getter/setter 進行限定，只讓使用者修改你允許修改的屬性。

其次，有利於版本升級。比如由於某些邏輯，獲取這個屬性之前你必須進行某些計算，那麼這個時候你直接更改 getter 方法實現，使用者進行升級即可，對使用者原有程式碼不會有影響。而如果之前是直接屬性訪問的話，你就麻煩了，你必須關閉 public 訪問許可權，然後提供 getter 方法，別人升級版本時，也必須去更改自己的程式碼，很是麻煩。

最後，就是整天說的那一套了，什麼面向物件，什麼封裝神馬的了

題主好，我來回答這個問題。

首先，透過g/s來獲取私有屬性的值，是javaBean規範中的一條，主要是為了把物件私有的那點小秘密藏起來，避免被壞人看到。

舉例說明，張三是一個物件，張三的錢包是他的一個屬性，當然張三為了安全起見，會把錢包藏起來，只有自己能看到，也就是說，錢包是private的。張三還有個坑爹兒子：小三子。因為有了小三子，張三就需要提供一個供小三子領生活費的方法，而不是直接把錢包暴露給小三子。因為，直接暴露給小三子的話，會有以下幾個問題：

1、張三控制不住小三子拿錢，萬一拿去買了遊戲面板就不好了；

2、張三有多少錢，都可以被小三子看到，但是很多時候，張三是不希望被小三子看到的（例如私房錢）；

3、小三子長大以後給張三生活費，給了多少張三也不知道，就好像得了老年痴呆一樣。

總之，透過方法來操作屬性的根本目的就是為了保護自己的私有屬性，不被外部直接訪問。

我先來說getter和setter的好處，再來說它們存在的歷史原因。

和直接訪問屬性相比，我們可以在getter和setter實現不同的控制權限(modifier)，比如說private的setter和public getter。我們還可以在getter和setter裡實現額外的邏輯，比如說：

public void setCounter(int c) { if (c < 0) { throw new IllegalArgumentException(); } this.counter = c; }

這樣做還有一個好處就是外部呼叫者是和getter和setter方法耦合，我們將來可以把這個類變成interface，你可能加入不同的實現類，比如說DBCounter， MemoryCounter，只要仍然向外暴露同樣的getter和setter，呼叫方就無需改變。

但現在getter和setter氾濫並不是因為這些好處，而是非常多的框架spring，struts，hibernate等依賴這種模式。

因為這個模式其實有個歷史原因，就是javabean，這是從jsp/servlet時代就開始有的概念，後來被非常多的Java 框架繼承。在很多框架中以pojo的形式出現, 它就是一堆屬性加上getter和setter再帶一個無引數的constructor，它被很多很多老框架廣泛採用，用於在不同層面傳遞資料，

但這個真的不是一個好設計，如果是來做model，你把所有私有屬性都暴露出來，這明顯是破壞了封裝。如果僅僅是在不同層面傳遞資料，那我覺得不可更改的物件似乎更適合。有setter的物件很容易產生問題，有些值不對的時候，你都不知道在哪改的，也不好debug。

另外在併發情況下，我比較推薦使用immutable(內部狀態無法再修改的)的物件，用一個constructor來初始化所有field, 然後只提供getters。這樣至少能保證每一個bean初始化出來都是完整的。傳統javabean你初始化需要呼叫一大組setter, 萬一中間出現異常，你這個bean很可能處在一種不可預計的狀態中，是很危險的。有朋友說，有的框架一定要依賴setter來賦值，的確有這種情況，那我想不出什麼更好的辦法，似乎這種情況下setter不能避免。但即便有setter，你自己的程式碼裡也可以不呼叫setter. 因為mutable的壞處聊起來沒底的。

明確地告訴題主getter/setter方法是java語言中封裝性的表現形式。

眾所周知，面向物件有三個基本特徵，封裝、繼承、多型。封裝好處非常多，比較有代表性的有以下幾個：一是防止外面隨意訪問內部的方法和資料，內部資料在程式設計時是類的私有方法或者私有成員。二是隱藏內部實現細節，每個類中基本都會有僅供自身呼叫的方法，這些方法他人是無需瞭解具體細節的。

舉個栗子佐證一下，大家平時開的汽車就就具有很好的封裝性。在使用的過程中，我們常做的是加油和駕駛這兩件事，其中加油與setter方法類似，駕駛則與getter方法類似。汽油怎麼轉化成動力，發動機、電路的工作原理，除了設計師和維修師又有誰關心呢？

如果不用，技術上完全可以直接把變數定義為public直接訪問。但這只是說技術上。實際專案中不會這麼做。

那很多人可能會想為什麼要這麼麻煩呢？因為用函式封裝可以隱藏內部實現。

舉個例子，比如有一個正方形的類，內部儲存了正方形相對於螢幕的位置，但是這個位置是正方形的左上角座標，有一個函式getPosition返回這個座標，那麼第一版可能就是直接返回的這個位置變數。但是隨著程式的開發，更多的時候需要用到正方形的中心位置，而類的內部也不需要用到左上角座標了，所以對類的內部進行了修改，刪除了這個座標變數。

那麼如果沒有封裝的話，就不能輕易修改這個類，一但修改，曾經所有用到左上角位置變數的地方就都需要修改。那將是天大的災難。但是有了封裝，曾經使用的地方，其實用的是一個函式。那我們修改類的時候只要修改一下這個函式的內部演算法，用中心位置計算一下左上角位置返回出去，那麼對於用到這個函式的地方根本不需要修改，因為他們並不知道也不需要知道類內部調整了，繼續用就可以了。也不會出現問題。而類的內部我們做的任何修改，只要不影響之前函式的功能，就沒有問題。這個就是封裝的好處。

所以才會有get/set函式，不單單是java，c++等只要是面相物件的程式語言都一樣的，這個是一個程式設計的思想。而並非是java獨有。

說個最簡單的例子。

如果有個類Person,裡面有個age屬性。正常來說這個age屬性是不可能小於0的。

如果沒有get/set，我們會直接操作這個屬性，那這個屬性值可以說就沒有任何限制。

但是我們透過get/set進行設值和取值，我們就可以在set或get方法中加入一些檢驗，用來檢查age設入的值是否合理。這就是我們說的封裝。

簡單來說這是java語言的封裝特性。所謂封裝，可以理解為一個黑盒子，以及黑盒子面板的露出去的可操作按鈕。黑盒子裡面很複雜，不需要給別人看，黑盒子外面的按鈕是供給外面使用的，這樣的封裝效果使得程式的可讀性，安全性以及維護性都大大增強了。有人說不要g/s行不行？當然是可以的，這樣需要把資料變數改成public就行，直接暴露在黑盒子外面，自己只要會操作也沒有問題，我經常做一些科研工作為了圖方便就是這麼處理的。但是如果是去網際網路公司工作，建議還是按照公司的規定和標準進行規範化程式設計。