「過分」地追求 OOP 有意義嗎？

01-27

這並不僅僅是OOP的問題，另一方面是「讓代碼易讀」。遵循語言提倡的Guideline編寫代碼，是為了讓他人和多年後的自己更快理解你所寫的代碼。

我的觀點是你們老師只是為了讓你們了解oop的使用方式而已，但是沒有具體說oop的最佳實踐。如果你從網路端獲取到的是一個string類型的age。但是你要使用的是int類型的age。那麼我們就可以在聲明一個private的string類型的age用來存儲網路端獲得的數據，再定義一個public的int getAge();用來獲取int類型的age，而getAge中簡單地進行string到int的轉化。

這裡舉了一個很簡單的例子，主要用來說明函數的目的是用來封裝的，用來隱藏細節的。

或者你的age是readonly類型的，那麼就只提供getter方法，而不要提供setter方法。

好處很多的，而且這裡的getter和setter方法方法命名習慣很好，你只要在智能補全下，輸入get，就可以知道這個對象有哪些getter方法了。

同學們這個代碼可以參考一下https://github.com/citerus/dddsample-core

getter setter 這種java bean只用在DTO

domain所有的方法都跟業務相關不破壞封裝

domain driven design 是我見過最能體現OO的實踐方法

正常情況下不是應該把變數設置成private然後通過成員函數訪問么？那樣必然不能直接對age進行賦值操作呀！

getter和setter的好處在於可以在獲取和設置屬性時對屬性進行約束。如果你的屬性不需要有任何約束，那麼仍然使用getter和setter顯然是十分教條主義的。

在編寫代碼時，如果沒有明確的擴展要求，我個人傾向於盡量final化，盡量私有化。有人覺得這麼做不利於後續的擴展，這裡有一點需要明確的是，在寫代碼之前就必須知道日後是否需要擴展，而不是給日後的心血來潮留個後門。

再過分都不為過

這個例子一點也不過分但是有的時候過度強調OO真的會使結構過於複雜

就算是個人寫程序，保持這個習慣也挺好

當你的程序越來越大，這個類在更多的地方被使用，某天你突然間要想改動時，就沒這麼擔心

過分追求肯定是不好的，過分本來就是個貶義詞。然而你說的情況在稍微有點規模的開發中並沒有過分追求oop。

請注意下面這段代碼（見Java編程思想#P156，略有省略）：

class Super { public int field = 0; public int getField() { return field; } }


class Sub extends Super {

    public int field = 1;

    public int getField() { return field; }

}

public class FileldAccess { public static void main(String[] args) { Super sup = new Sub(); System.out.println("sup.field = " + sup.field + ", sup.getField() = " + sup.getField()); Sub sub = new Sub(); System.out.println("sub.field = " + sub.field + ", sub.getField() = " + sub.getField()); } }

你覺得列印的是多少？

&>&>

/*Output:

sup.field = 0, sup.getField() = 1

sub.field = 1, sub.getField() = 1

不暴露變數，安全性，擴展性比較好

既然是過分，當然就沒有必要，提問本身就是廢話。當然我還是願意回答你的問題，什麼情況下封裝才是合適的。合理封裝必須有意義才行，滿足架構需要、分工協作、維護方便等。如果你自己一個人用想怎麼寫就怎麼寫。

理論上你把代碼寫成義大利麵條也沒什麼關係，只要能跑起來。

實際上代碼不是你一個人的，不遵循某一套約定俗稱的規範，會給其他人造成困惑，降低整個團隊的效率，是損人不利己的行為。

退一步說，現在還有誰手寫getter和setter了，只要點點按鈕就自動生成了。

這不過分 encapsulation的意義是什麼？你的stletter里必然要有sanity check。很簡單，你既然不想別人把你的年齡設成十萬，而且這個不正常的數在後面也很有可能crash你的程序。

沒和學生講明白並不叫過分

跟OOP關係不大，編程講究模塊化，弱耦合，盡量把對一個數據對象的操作包含到一個地方里，便於跟蹤和重用。

1，oop的原則是暴露方法和介面，隱藏內部實現。

2，在getter/setter內部可以做一些計算和校驗工作。

3，一些IDE可以方便地生成getter/setter，比如Android Studio。

4，部分效率優先的語言（比如C++）或者庫（opencv），也會稍微違反這個原則以獲得更高的調用效率，可以直接訪問對象內部的成員變數。

5，學校時掌握原則，打好基礎，實際運用時根據需求靈活使用。

Oop是一種開發理念。當然這麼說你也不懂。

然而並發時代，mutability is evil。如無充分理由，age應該聲明為final，那就沒setter什麼事了。這樣getter里做的事情就可以提前到構造函數，所以最後直接 public final 是墜吼的

「過分」, 肯定是沒有意義的

送分題，沒有