不是“一定”要如此，變數或資料、功能是否需要包裝、如何包裝，由它們本身的性質決定，即邏輯應該如何就是如何。

來個更直觀的吧：

1. 變數代表的是資料和實現的輔助記錄，而通常需要的是功能、功能的實現可能改進、不只是基於變數A。所以，通常我們提供的是函式，少數時候也會公開變數。

2. 程式碼的維護和閱讀，如果變數可以外部肆意篡改，在閱讀和維護本類的實現時，最佳化實現和調整就變得很困難了。

封裝的作用：隱藏內部實現，讓訪問方更關注功能；更強的內聚，利於閱讀和維護、最佳化；還有更進一步的模型和思路引導，利於模組和系統的抽象。

這得分情況來看，程式語言有有兩個極端：

一種是把使用者當賊防，以“使用者必然會犯錯”為原則，這時候就會盡可能地封裝，約束使用者的行為。以Java為代表。優點是使用者門檻低，能夠讓開發者快速上手現成程式碼，缺點是開發效率低。

一種是把使用者當上帝，你想幹嘛就想幹嘛。以C/Python為代表，你甚至在Python執行的時候修改程式碼本身，優點是開發效率高，缺點是使用門檻高，很容易就入坑。當然，因為夠自由，所以你在使用的時候，可以人為地設定“約束”，也就是自我封裝，得所有經手你程式碼的開發者都遵從你的“條約”。

還有大量的語言在這兩個極端之間，期望能夠達到一個平衡，例如Rust。

封裝不代表“好”，或者“壞”，得看你所使用語言的“最佳實踐”。遵從“最佳實踐”，配合實際情況寫出來的程式才是好程式。

題主說的是全域性變數吧。

程式如果都使用全域性變數，那個程式就只能由編寫程式的人維護和修改，別人想維護和修改，就要完全讀懂這個程式的原始碼，幾十條可以，程式大了誰也做不到，這個程式就是一個死程式了。

如果使用封裝，每一個封裝都有入口和出口，你把入口和出口弄清楚就可以了，幾條註釋就能辦到，而不需要你去讀懂源程式，甚至都不需要你有源程式。

引用直接用屬性沒辦法監聽使用者動作，或者做一些其他處理。比如有的屬性可以沒有變數對應，比如我想監聽使用者對某個值更新，比如我對屬性輸出做一些加工。

使用javabean是個規範，在JavaScript中也隱含了這個規範，所以vue,react等可以監聽屬性變化

封裝，主要來自於面向物件程式設計。具體做法是將類(class)裡面的一部分變數和一部分方法(或函式)設定為私有，不允許外部訪問。透過對外暴露一些公有的方法、函式、欄位、屬性、事件(不同程式語言叫法不一樣)，來實現封裝。

封裝的好處大概有以下幾點：

舉個簡單例子，設計一個機械時鐘的類，通常會有兩個重要變數，一個是時針、一個是分針。如果沒有封裝，而是直接對外暴露，就會導致時針分針錯亂。比方說，6:30，分鐘指向30，時針應該指向6和7的正中間。如果不封裝，時鐘就容易指錯位置。如果是電子時鐘，還會出現分鐘超過60，小時超過24的情況。相反，封裝得好，只對外暴露調節旋鈕的功能，則時針分針的顯示絕對不會出錯。如果是電子時鐘，則可以在內部統一對輸入的時、分變數進行範圍校驗或修正(而不是將此功能轉嫁給外部呼叫者)。總之，封裝得好，不論外部如何呼叫，在任何時候都不會出現時、分出錯，將bug扼殺在搖籃裡。

在面向物件程式設計中，我們呼叫一個物件的成員時，只會顯示公有的成員。這樣就會大大降低學習和維護的難度。試想，假設一個類有100個成員，如果採用公有私有封裝，只公開20個，那麼，呼叫者只需要學習這20個就足夠了，否則，就需要學習100個。同時，如果可以選擇的東西太多時，就會導致“選擇恐懼”或者產生困擾。不要說自己寫的，不需要“學習”。因為當你時間久了後，肯定要遺忘之前寫的程式碼的。另外，現在大部分IDE都自帶程式碼智慧補全功能，在物件後面輸入一個點，就直接出來公有變數，用起來非常方便。相反，面向過程或者沒有良好封裝時，就享受不了這個好處，需要不斷地檢視文件來尋求幫助。

估計大部分人都能很好地理解上面兩點，但就是不知道明明可以直接訪問變數，為什麼卻非要搞個getter/setter。實際上，很多時候確實沒有必要，僅僅就是為了所謂的規範。但是卻存在一種情況，當我們想跟蹤某個變數到底在什麼時候被呼叫，特別是被改變時，就很有用了。只需要在getter/setter中臨時加入一些跟蹤程式碼，比如日誌列印，就能輕鬆查出來。這在遇到bug時，非常有幫助。

還有一種情況就是getter/setter可以更方便地使用反射技術，這在使用某些大型框架時經常用到。

以上所說，在大型專案，多人開發時，表現得特別明顯。如果只是一個人，只是寫個小程式，或者臨時小工具(比如運維、簡單資料處理)，那估計體會不到封裝的好處，也沒有必要過度封裝。

但是，也需要意識到，一些優秀大型專案，也有封裝不良好的情況，有的還用到了面向過程的技術。這是因為，這部分程式碼，可能會非常底層、非常強調效能(比如作業系統、編譯器、高效能科學計算)。不過，咱們普通人就不用想了，還達不到那個水平，就老老實實把封裝技術用好吧。

那是因為內部某些演算法非常複雜或者麻煩 不允許外人胡亂改動 打比方

列表長度是明明是10 size返回5 因為你設定size是5 封裝的好處是不需要你去關注內部實現邏輯 你只要呼叫就完事了

那是因為內部某些演算法非常複雜或者麻煩 不允許外人胡亂改動 打比方

列表長度是明明是10 size返回5 因為你設定size是5 封裝的好處是不需要你去關注內部實現邏輯 你只要呼叫就完事了

跟你舉個例子吧！

銀行會不會直接讓使用者去操作 銀行資料庫？

不會，因為使用者可能把自己的餘額改成1億，

所以封裝一下， 銀行具有辦理視窗，讓銀行職員操作銀行系統幫你辦理相關業務！！！

實際開發中沒你說的那麼簡單。要看具體情況的，只是常規低技術的業務程式開發中一般建議使用封裝，而不是直接訪問。但是如果在作業系統開發，驅動開發，或者高效能高併發最佳化等等方面的時候，也許就會考慮直接訪問記憶體地址了。有一種最佳化叫做縮短io路徑，本質上就是減少呼叫層次，儘量直接訪問記憶體來完成最佳化。

看了前面的回答都沒有回答到重點。大多數getter跟setter都是沒有任何邏輯的，就是直接get和set變數值，那為什麼還需要getter和setter呢？原因就是為了單元測試。單元測試框架只能mock方法，不能mock變數。Mock方法不只是為了知道最後的變數值是多少，還可以知道這個變數值被讀了多少次，寫了多少次。這都是單元測試中經常用到的技巧。

無封裝：

賬戶.餘額 = 1000000000000000000

有封裝：

賬戶.set餘額(值) {

各種許可權判斷 {

this.餘額 = 值

}

}