很久很久以前寫了兩篇設(shè)計(jì)模式亂用的文章，最近心血來(lái)潮，突然想寫篇OOP亂用。

最近在移植一個(gè)舊項(xiàng)目，接手過(guò)程很多嘈想吐，開一篇談一下OOP的亂用。

大多數(shù)公司用MVC是為了解耦合，但是這套代碼的MVC明顯是不解耦的，例如View1可以直接拿view2單例如調(diào)用里面的方法。v可以調(diào)用c,c可以隨意調(diào)用v。不同人寫的c和v可以隨意調(diào)用?？雌饋?lái)寫得爽，但是修改起來(lái)就各種吐了，當(dāng)你修改一個(gè)v的時(shí)候，我還得讀一下耦合的另一個(gè)v的相關(guān)代碼。這段話說(shuō)得暈暈的，下面直接說(shuō)簡(jiǎn)單的OOP的亂用吧。

繼承和復(fù)蓋，相信寫過(guò)代碼的人都懂，也很簡(jiǎn)單。但是真正寫代碼的時(shí)候，什么情況下用繼承呢？直接說(shuō)反例得了。例如項(xiàng)目有一個(gè)加速的界面，很多模塊會(huì)用到，但是各模塊對(duì)這個(gè)界面的顯示有一些不一樣，例如A模塊比B模塊多一個(gè)按鈕。很多人的想到的方法是在這個(gè)加速界面里面加type處理，不同模塊有不同的type，然后再加一個(gè)param，處理不同模塊的邏輯，想到這個(gè)方法的人面壁去吧。這個(gè)就是當(dāng)前我接手的項(xiàng)目的最大問(wèn)題了。這種做法實(shí)際上是亂用工廠模式，簡(jiǎn)單的說(shuō)，問(wèn)題就是去別人的加速模塊加type處理自己的邏輯。當(dāng)新項(xiàng)目想移植加速面板的時(shí)候，發(fā)現(xiàn)這個(gè)加速面板耦合大量模塊，移植的時(shí)候，我要移A的加速面板，還得考慮B的加速邏輯。所以很多人說(shuō)改別人的代碼還不如自己寫一個(gè)新的來(lái)得快。

既然說(shuō)出了問(wèn)題，我們?cè)僬f(shuō)說(shuō)解決方案，相信有經(jīng)驗(yàn)的人早就想到了。把加速面板做成一個(gè)基類，不同模塊新建一個(gè)自己的面板繼承那個(gè)基類加速板，處理邏輯如果有少量不同的地方就復(fù)蓋繼承處理就行了。思路很簡(jiǎn)單，下面看看好處吧，各模塊寫自己的加速面板時(shí)，就是自己寫自己的，完全不會(huì)跟別人的加速面板有關(guān)，也不需要去改別人的模塊。移植新項(xiàng)目的時(shí)候，移一個(gè)模塊就看一個(gè)模塊的代碼，移植A模塊的加速面板就完全不需要管B怎么寫的(除非改動(dòng)基類加速面板)。這樣看誰(shuí)還敢說(shuō)自己全新寫的快。


舊代碼雖然用了mvc，雖然對(duì)象都繼承了基礎(chǔ)的view，基礎(chǔ)的model，基礎(chǔ)的ctrl，然并卵。M和C都是單例，view雖然不是單例，但是放在單例上面給其它單例調(diào)用，代碼依然還是像沒(méi)用oop一樣，很過(guò)程式的寫法。既然不做解耦，那何必花這么多碼量寫這么多繼承做什么。直接搞全局方法不還寫得快。

吐嘈完畢，本來(lái)還想吐mvc的，發(fā)現(xiàn)文字量不少，今天先不吐先，下一篇我要吐亂用注入函數(shù)。