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

最近在移植一個舊項目，接手過程很多嘈想吐，開一篇談一下OOP的亂用。

大多數(shù)公司用MVC是為了解耦合，但是這套代碼的MVC明顯是不解耦的，例如View1可以直接拿view2單例如調(diào)用里面的方法。v可以調(diào)用c,c可以隨意調(diào)用v。不同人寫的c和v可以隨意調(diào)用?？雌饋韺懙盟切薷钠饋砭透鞣N吐了，當(dāng)你修改一個v的時候，我還得讀一下耦合的另一個v的相關(guān)代碼。這段話說得暈暈的，下面直接說簡單的OOP的亂用吧。

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

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


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

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