在工作中，已經形成了一個習慣，常常在新加一個類時，在寫好一些private變量之後，會順手自動生成相應的getter/setter方法。《Clean Code》中提到
將變量設置爲private有一個理由：我們不想其他人依賴這些變量
確認，但是存在很多的規約是將public的變量使用private加getter/setter的方式來呈現，這兩種方式都沒關係，看個人喜好。
但我們工作中的變量真的都是public的麼，很多場景並不是。
第一種是隻讀變量，這種情況不希望外部可以修改，只能通過配置或者其他的方式來進行初始化。
第二種是純私有變量，這種情況完全不希望外部依賴。
只有setter的變量比較少見，控制getter/setter的方式主要是方便控制依賴，便於變量的管控。加入有一個訂單模型Order，裏面有一個Map結構，當bizType的key值爲A的時候代表AA業務方的訂單，如果把Order的Map暴露出去，就會有很多其他的業務方來根據bizType來判斷AA業務訂單，如果想要去使用bizType爲B來表示AA的業務訂單，就需要通知所有使用了Map原始值來判斷的業務方來修改，因此，儘量讓別人來依賴接口而非實現，而控制getter就是一種較好的途徑。
除了依賴管理之外，另外一個好處就是便於閱讀，如果我們都是不加思索的添加各種getter方法，就會出現類似ctx.getA().getB()這樣的級聯調用，除了容易出現NPE之外，還強迫閱讀者去理解所有的細節，甚至去跳躍的閱讀。如果謹慎的使用getter的話會去強迫自己思考有沒有更加抽象的方式來提供服務，讓閱讀者一目瞭然。
爲了實現同樣的功能，可以使用多態以及單一處理器的方式來實現，單一處理器要求對象提供getter方法，然後處理器來計算所有邏輯，這種方式的好處是添加方法時在一個類修改就好了。但是我覺得這種優勢並不明顯，首先是所有的實現類的情況都需要考慮到，代碼量並沒有減少，其次如果新增了一個實現類，處理器的邏輯容易遺漏，只有在執行階段才發現問題，而通過多態的方式在編譯階段就可以發現，因此這種情況下也推薦使用多態方式，保持變量的私有化。
