面向對象程式設計亂彈

可以先看看代碼對比，精華都在代碼裡：

基于類的方式改寫：

<a href="http://git.oschina.net/web3d/DeCMF/commit/58f915b9d24ab5ffe40adf4ad4ed769fdb6ebe6e">http://git.oschina.net/web3d/DeCMF/commit/58f915b9d24ab5ffe40adf4ad4ed769fdb6ebe6e</a>

原來的函數形式：

<a href="http://git.oschina.net/web3d/DeCMF/commit/228983fb76b7bd6b69e6116d984ebfe7454d4b8d">http://git.oschina.net/web3d/DeCMF/commit/228983fb76b7bd6b69e6116d984ebfe7454d4b8d</a>

這個項目是為了示範OOP程式設計實踐而建立的，基于OneThink CM架構。

上述代碼，将一個函數的代碼，拆分到兩個類中-父子類繼承，在後續整理的過程中，就發現了這樣的好處，函數庫中另一個類直接代碼重用了。

get_addon_list函數的改寫：

<a href="http://git.oschina.net/web3d/DeCMF/commit/9ae6a2fe9abe27789a1d1c0982d20f97950c1895">http://git.oschina.net/web3d/DeCMF/commit/9ae6a2fe9abe27789a1d1c0982d20f97950c1895</a>

原本的一個get_list_field 函數58行，基于面向對象的方式初步改寫後，變成240多行，咋一看，代碼行數多了很多，不科學啊！

但仔細看後，除去注釋90行、語句換行大緻20行，其他嵌套語句拆分10幾行，原本缺少的邏輯細化，并沒有真正增加幾行代碼。

其實，OOP代碼更多是個僞命題，我隻是想以此為話題，回顧一下OOP！

面向對象好像對很多人不是個事，但其實隻是大多數人沒有真正去在意什麼是OOP。

OOP的三大特性：

1.封裝

把過程和資料包圍起來，隻讓可信的類或者對象操作，對不可信的進行資訊隐藏。

2.繼承

通過過程抽象和資料抽象。理出一般與特殊的關系。代碼重用。

3.多态

不同類的對象對同一消息作出響應的過程不同。接口重用！

将所有邏輯塞到一個函數或者類方法中是沒有差別的，這不是面向對象，也不是面向對象的初衷，設計OOP的初衷是解決代碼的重用問題。現實中代碼的重用程度好像并沒有一個明确的标準，是以不同的人實踐後會有不同程度的接受度。

通過面向對象，我們要找到相關資料和功能邏輯的關系，并與外界相對隔離，專心專意的去解決一個問題，不會因為暴露出來的全局變量或者函數影響整體代碼的可讀性和可維護性；同時，考慮事物的多态性，分層去定義對象的屬性與功能。

在團隊項目中，一坨垃圾代碼我們要維護很久很久，直到受不了離開為止。或者是新團隊，從頭開始寫，用最牛掰的架構，最牛掰的架構，寫出一坨垃圾代碼，然後維護很久很久，直到受不了離開為止......

是以，能否戰勝垃圾代碼，其實才是真正檢驗程式員水準的标準。面試了很多人，也有一些新人加入團隊後不久就離開，标準理由都是，項目太複雜了，代碼太垃圾了，最好能從頭開始一個新系統、或者給我一年時間重構現在的系統！

我隻能不屑的一笑：你們都是懦夫，真正的程式員敢于直面垃圾的代碼，敢于正視破碎的系統！

這是怎樣的哀痛者和幸福者？然而造化又常常為平庸的程式員設計，以時間的流逝，來洗滌舊邏輯，僅使留下蒼白的産品和微漠的悲哀。在這蒼白的産品和微漠的悲哀中，又給程式員暫得偷生，維持着這似是而非的系統。你不知道這樣的系統何時是一個盡頭！

但我知道！OOP是沒有盡頭的！