面向?qū)ο缶幊讨螅?/h1>
[導(dǎo)讀]“我是舊時(shí)代的殘黨，新時(shí)代沒有承載我的船?！比绻嫦?qū)ο缶幊淌且粋€(gè)人，我猜他自己在不斷被非議的今天，一定會(huì)這樣感慨。說實(shí)話，我用面向?qū)ο蠓绞骄幊桃呀?jīng)十幾年了，我做架構(gòu)設(shè)計(jì)離不開它，做系統(tǒng)分析離不開它，編碼的時(shí)候更是嚴(yán)重依賴它，我對(duì)面向?qū)ο鬅o論是思想上還是寫代碼上都對(duì)它是有很深的感...
“我是舊時(shí)代的殘黨，新時(shí)代沒有承載我的船?！?/p>如果面向?qū)ο缶幊?/a>是一個(gè)人，我猜他自己在不斷被非議的今天，一定會(huì)這樣感慨。說實(shí)話，我用面向?qū)ο蠓绞骄幊桃呀?jīng)十幾年了，我做架構(gòu)設(shè)計(jì)離不開它，做系統(tǒng)分析離不開它，編碼的時(shí)候更是嚴(yán)重依賴它，我對(duì)面向?qū)ο鬅o論是思想上還是寫代碼上都對(duì)它是有很深的感情。剛學(xué) Java 的時(shí)候，我覺得面向?qū)ο缶幊蹋∣OP）真牛逼，用面向?qū)ο蠓绞綄懗鰜淼拇a是最好的代碼。但是隨著項(xiàng)目越做越多，代碼越寫越多，我發(fā)現(xiàn) OOP 不是萬能的，盲目的迷信追求 OOP 會(huì)有代價(jià)。今天這篇文章我不是說面向?qū)ο蟛缓?，只是希望大家不要過度神話它，更不要人云亦云。大家都聽說過
3. 多態(tài)好，但可能是面向?qū)ο蟮呢澨熘?/h2>再說說多態(tài)。其實(shí)，面向?qū)ο笾械亩鄳B(tài)使用，才是面向?qū)ο笳Z言最被認(rèn)可的地方。因?yàn)橛辛硕鄳B(tài)，代碼才能保證在業(yè)務(wù)需求多變的情況下，保證了項(xiàng)目的相對(duì)穩(wěn)定。可是，多態(tài)不是面向?qū)ο螵?dú)有的啊。面向過程，函數(shù)式編程也可以：面向過程里，C 語言可以靠虛函數(shù)去在運(yùn)行時(shí)加載對(duì)應(yīng)的函數(shù)實(shí)現(xiàn)去實(shí)現(xiàn)多態(tài)。函數(shù)式編程也可以通過組合函數(shù)去實(shí)現(xiàn)多態(tài)。所以，面向?qū)ο筮B多態(tài)這種優(yōu)勢(shì)都不獨(dú)特了。
面向?qū)ο蟮娜筇匦裕豪^承、封裝、多態(tài)但其實(shí)這個(gè)說法有問題。面向?qū)ο蟮乃枷肜餂]有任何繼承和多態(tài)的概念，正確的說法是：這三大特性是面向?qū)ο笳Z言的特性，而不是面向?qū)ο罄砟畋旧淼摹?/p>面向?qū)ο笳Z言是面向?qū)ο笤O(shè)計(jì)思想的一種實(shí)現(xiàn)，面向?qū)ο笳Z言為了能在真實(shí)世界使用，其必須經(jīng)過一些拓展和妥協(xié)，而問題也就隨著這些拓展和妥協(xié)而來。
1. 繼承帶來的也可能是無以復(fù)加的痛苦
在實(shí)際開發(fā)中，我們無論誰寫代碼，都要考慮代碼的復(fù)用性。面向?qū)ο蟮木幊陶Z言作為給開發(fā)人員使用的工具，它也必須考慮到復(fù)用性。所以，在面向?qū)ο缶幊陶Z言里，對(duì)面向?qū)ο蟮幕A(chǔ)思想做了拓展，搞出了繼承這個(gè)概念。繼承就具體實(shí)現(xiàn)來說，就是子類擁有父類的所有非 private 的屬性和方法。繼承的出現(xiàn)能夠最大化的代碼復(fù)用。當(dāng)項(xiàng)目里一個(gè)類已經(jīng)有了我們需要的屬性和方法，而我們現(xiàn)在的需求只是在這個(gè)已有類的基礎(chǔ)上有些許的不同，我們只需要繼承這個(gè)類，僅把這少許的不同在子類中實(shí)現(xiàn)即可。但是如果你用了繼承，你就引入了問題。繼承的出現(xiàn)天然會(huì)使得子類和父類緊耦合。也就是說，父類和子類是緊密關(guān)聯(lián)的，牽一發(fā)動(dòng)全身。如果現(xiàn)實(shí)世界里，所有業(yè)務(wù)模型都是有層次的，而且層次井然有序，是一顆天然的樹，那這種緊耦合沒有什么問題。但是現(xiàn)實(shí)的需求可不是吃干飯的！咱們看看這樣一種情況。假設(shè)現(xiàn)在我們一家只有兩口人，即只有父親和孩子，那么類繼承模型很容易模擬這種情況：class?Super?{
??private?int?counter?=?0;
??void?inc1()?{
????counter ;
??}
??void?inc2()?{
????counter ;
??}
}
class?Sub?extends?Super?{
??@Override
??void?inc2()?{
????inc1();
??}
}
你看，子類覆蓋了父類的 inc2 方法，但是這個(gè) inc2 方法依賴于父類 inc1 的實(shí)現(xiàn)。如果父類的 inc1 邏輯發(fā)生變化了，變成下面這樣class?Super?{
??private?int?counter?=?0;
??void?inc1()?{
????inc2();
??}
??void?inc2()?{
????counter ;
??}
}
這就會(huì)出現(xiàn) stack overflow 的異常，因?yàn)槌霈F(xiàn)了無限遞歸。所以，當(dāng)我們?cè)谧宇惱?，依賴了父類方法作為子類業(yè)務(wù)邏輯的一個(gè)關(guān)鍵步驟的時(shí)候，當(dāng)父類的邏輯修改的時(shí)候，必須聯(lián)動(dòng)修改所有依賴父類相關(guān)邏輯的子類，否則就可能引發(fā)嚴(yán)重的問題。用繼承，本來是想少寫點(diǎn)代碼少加點(diǎn)班，結(jié)果……用網(wǎng)上看到的一句話說就是：一日為父，終生是祖宗。像這種情況該怎么辦？現(xiàn)在只要是個(gè)正經(jīng)的介紹面向?qū)ο蟮募夹g(shù)文章或者書籍里，只要是涉及到繼承的，都會(huì)加這么句話：盡量選擇對(duì)象組合的設(shè)計(jì)方式。在《阿里巴巴Java開發(fā)手冊(cè)》中就有一條：
2. 封裝如同帶有漏洞的封印，可能會(huì)逃逸出魔王
封裝，說白了就是把屬性、方法，封到一個(gè)對(duì)象里，這是面向?qū)ο蟮暮诵睦砟睢?/p>嘴上叫封裝，卻開了個(gè)縫兒。我們知道，項(xiàng)目是既要兼顧代碼質(zhì)量，還要兼顧運(yùn)行性能的。不可能說為了提升什么松耦合、高內(nèi)聚，就不管不顧性能了。事情就壞在了這個(gè)兼顧性能這里。面向?qū)ο罄?，以上帝角度看，系統(tǒng)就是對(duì)象和對(duì)象之間的關(guān)系構(gòu)造成的網(wǎng)絡(luò)。就拿咱們上面談到的組合關(guān)系來說，組合關(guān)系的實(shí)現(xiàn)就是通過把一個(gè)對(duì)象當(dāng)成另一個(gè)對(duì)象的屬性來實(shí)現(xiàn)的。A?a?=?new?A();
B?b?=?a.getB();
好，我們要問了，這個(gè)從 A 中獲取的 B，是 B 對(duì)象的實(shí)例還是實(shí)例的一個(gè)引用指針呢？必然是引用指針吧，這是最基礎(chǔ)的知識(shí)。諾，問題來了，引用指針是可以修改的。b.getS();?//原來是Hello?World
b.setS("World");//直接改成World
原來 B 中有個(gè)字段 s，值是個(gè) “Hello World”，我直接可以用代碼改成“World”。如果這次修改隨意在個(gè)犄角旮旯里，A 能知道嗎？A 蒙在鼓里，還以為一切盡在把控當(dāng)中呢。你看，封裝的縫兒出來了吧。說句實(shí)話，就這種鬼操作，是非常難以排查的。像這種封裝了，但是又沒封裝的問題，我只想說“封裝的挺好的，下次別封裝了”。
下載文檔
